|
0 / 0 / 0 Регистрация: 27.06.2022 Сообщений: 7 |
|
|
1 |
|
Маленькая ошибка бд Поставка товаров27.06.2022, 18:07. Показов 793. Ответов 12
Добрый день уважаемые пользователи данного сайте. Мне нужна ваша помощь с одной маленькой ошибкой. Кликните здесь для просмотра всего текста https://************/6a6f03aa94b9223fa3c19d89f1b9e4f9 Вроде бы всё правильно и даже результат появляется Кликните здесь для просмотра всего текста https://************/2766dbbb76086500c969e3d8fa67d877 Но при попытки добавить новые товары, появляется данная ошибка Кликните здесь для просмотра всего текста https://************/3e6440a750e4c4a54bd6d6016a30f192 Пытался несколькими простыми движения решить эту проблему, но как видите не смог.
0 |
|
17320 / 7146 / 1614 Регистрация: 21.06.2012 Сообщений: 13,488 |
|
|
27.06.2022, 18:16 |
2 |
|
Так как я не знаю, можно ли размешать скрины из acess Здесь нужно размешать свою архивированную базу, а не ссылки на картинки … . Читайте Правила раздела.
0 |
|
0 / 0 / 0 Регистрация: 27.06.2022 Сообщений: 7 |
|
|
27.06.2022, 18:17 [ТС] |
3 |
|
Добрый день уважаемые пользователи данного сайте. Мне нужна ваша помощь с одной маленькой ошибкой.
Но при попытки добавить новые товары, появляется данная ошибка
Как я понял, добавлять ссылки тоже нельзя. Пытался несколькими простыми движения решить эту проблему, но как видите не смог.
0 |
|
0 / 0 / 0 Регистрация: 27.06.2022 Сообщений: 7 |
|
|
27.06.2022, 18:19 [ТС] |
4 |
|
Скажите, пожалуйста, нужно именно в архиве кинуть, или можно без него?
0 |
|
0 / 0 / 0 Регистрация: 27.06.2022 Сообщений: 7 |
|
|
27.06.2022, 18:24 [ТС] |
5 |
|
Вот собственно файл.
0 |
|
Модератор
5426 / 2681 / 661 Регистрация: 12.06.2016 Сообщений: 7,108 |
|
|
27.06.2022, 18:52 |
6 |
|
нужно именно в архиве кинуть, или можно без него? Без архива БД на сайт не загрузится. Добавлено через 3 минуты Кто же Вам так ссылки поуродовал? Были бы нормальные, я посадила бы сюда картинки вместо ссылок.
0 |
|
0 / 0 / 0 Регистрация: 27.06.2022 Сообщений: 7 |
|
|
27.06.2022, 19:11 [ТС] |
7 |
|
Там вместо звездочек вот это ************ Добавлено через 12 минут Добавлено через 3 минуты
0 |
|
Модератор
5426 / 2681 / 661 Регистрация: 12.06.2016 Сообщений: 7,108 |
|
|
27.06.2022, 19:19 |
8 |
|
NoneN, Темы не удаляются по желанию пользователя. Но можете в качестве благотворительности для последующих поколений изложить решение.
0 |
|
0 / 0 / 0 Регистрация: 27.06.2022 Сообщений: 7 |
|
|
27.06.2022, 19:27 [ТС] |
9 |
|
Я бы с радостью, но как оказалось, проблема не решена. По совету с другого сайта я решил проверить удалив 2 условия, но я случайно удалил и выражение, из за чего подумал что проблема решена. Поэтому, я и дальше нуждаюсь в помощи. ))
0 |
|
309 / 332 / 40 Регистрация: 06.03.2022 Сообщений: 1,687 |
|
|
28.06.2022, 01:10 |
10 |
|
прочтите и решите нужно ли Вам это поле Добавлено через 12 минут
0 |
|
7359 / 4497 / 292 Регистрация: 12.08.2011 Сообщений: 13,719 |
|
|
29.06.2022, 04:14 |
11 |
|
над схемой надо подумать Проще Как правило пункт 2 студенты не выполняют.
0 |
|
0 / 0 / 0 Регистрация: 27.06.2022 Сообщений: 7 |
|
|
29.06.2022, 09:09 [ТС] |
12 |
|
В общем, вчера мне препод помогла, возможно, сегодня выложу в чём заключалось проблема.
0 |
|
D1973 |
|
30.06.2022, 05:25
|
|
Не по теме:
Кто же Вам так ссылки поуродовал? Как правило эти занимается движок форума, ибо нефиг. Положено публиковать материалы на форуме — будь любезен. А ссылки на всякие файлообменники и онлайн-скриншотеры калечатся для невозможности перехода по ним.
0 |
MS Access. SQL. Ошибка распознавания команд CHECK и DEFAULT в MS ACCESS
В процессе создания SQL-скриптов может появляться ошибка, затем будут выделены операторы CHECK или DEFAULT.
Для устранения ошибки (применимо для MS Access 2007).
Кнопка Office (верхний левый угол) -> Параметры Access ->Конструктор объектов -> Конструктор запросов. Помечаем галочками Синтаксис для SQL Server (ANSI 92): эта БД.
Галочка может быть не доступна для не только что созданных баз данных. В этом случае необходимо создать новую базу данных и импортировать туда существующую.
Комментарии
MurCode
- Форумы
- Поиск
- О проекте
Ranger
Дата: 23.09.2003 08:52:47
При запуске на выполнение DTS пакета (для трансформации данных из SQL Server в Access97) при преобразовании одной из таблиц возникает ошибка:
«The number of failing rows exceeds the maximum specified.
Ошибка при определении значения ограничения CHECK.»
Причем возникает она не всегда, (т.к. я пробовал много раз выполнять это же преобразование при одних и тех же данных), т.е иногда трансформация проходит совсем без ошибок.
Что это вообще за ошибка, почему она то возникает, то нет?
Glory
Дата: 23.09.2003 10:25:55
возникает ошибка:
«The number of failing rows exceeds the maximum specified.
Ошибка при определении значения ограничения CHECK.»
«Ошибка при определении значения ограничения CHECK» может означать лишь «Ошибка при определении значения ограничения CHECK» Т.е. что в SQL имеется CHECK, которому не удовлетворяют какие-то записи из Access
Ranger
Дата: 23.09.2003 11:38:24
Сложно определить какая строка таблицы содержит ошибку, потому что ошибка возникает в разное время (может в начале прогресса преобразования, а может и в конце), а иногда трансформация проходит совсем без ошибок.
Почему возникновение ошибки носит случайный характер?
Glory
Дата: 23.09.2003 11:42:09
Сложно определить какая строка таблицы содержит ошибку, потому что ошибка возникает в разное время (может в начале прогресса преобразования, а может и в конце), а иногда трансформация проходит совсем без ошибок.
Почему возникновение ошибки носит случайный характер?
Ну так выясните какие CHECK constraint-ы у вас существуют для SQL таблицы и проверьте удовлетворяют ли им записи из таблицы Access
Ranger
Дата: 29.09.2003 11:53:54
Снял флажок «Check constrains» в DTS Properties — не помогло, ошибка все равно иногда появляется.
Зато выяснил, что ошибка вероятней всего появляется из-за копирования идентификационных полей.
У таблицы источника на SQL Server 2000 это поле
Type: int
Length: 4
Identify: Yes
Identify Seed: 1
Identify Increment: 1
У таблици приемника на Access 97 поле
Тип: счетчик
Размер: Длинное целое
Новые значения: случайные
Формат поля: основной
Индексированное поле: Да (Совпадения не допускаются)
Если это поле не копировать (значения будут присваиваится автоматически), то ошибки не возникает.
Glory
Дата: 29.09.2003 12:28:46
Если это поле не копировать (значения будут присваиваится автоматически), то ошибки не возникает.
Это означает лишь то, что вы пытаетесь добавить ошибочные данные. Тем более что «Индексированное поле: Да (Совпадения не допускаются) »
Ranger
Дата: 29.09.2003 13:33:29
С данными все нормально. Ведь копируются тоже значения идентификационного поля, где не может быть совпадений. А таблица-приемник перед копированием очищается.
А самое главное (уже в который раз отмечаю), при одних и тех же данных в исходной таблице и «чистой» приемной таблице трансформация данных может провестись как с ошибкой, так и безошибочно. Примерно 1 к 3 соответственно.
Всем привет, друзья! В этом уроке расскажу, что делать если появилась ошибка: Невозможно использовать несколько столбцов в ограничении CHECK уровня столбца. И сразу моделирую следующую ситуацию: у нас есть таблица, в которой создано всего два поля — это поле «дата 1» и поле «дата 2». Мы хотим, чтобы при вводе данных система проверяла, чтобы «дата 2» всегда была бы больше «дата 1».
Мы знаем, что в свойствах поля есть пункт «правило проверки». Давайте, мы здесь напишем следующее условие: «дата 2» больше поле «дата 1». Сохраняем внесенные изменения и получаем вот такую вот ошибку: «невозможно использовать несколько столбцов в ограничении CHECK уровня столбца».
Что же делать в таком случае? Так как в данном примере я хочу сравнить значение первого поля со значением другого поля, то правило проверки нужно задавать не в свойствах какого-то одного поля, а в свойствах всей таблицы. Кстати в более ранних версиях свойство «правило проверки» называлось «условие на значение». Давайте, мы данное выражение удалим и перейдем «вкладка» — «конструктор» — страница свойств.
Здесь также существуют правила проверки, мы нажимаем кнопку с тремя точками, у нас появляется построитель выражений, где у нас уже доступны поля созданной таблицы. Мы пишем «дата два» больше «дата один», нажимаем ok.
Где «сообщение об ошибке» давайте просто пропишем ошибку словами: «дата 2 всегда больше дата 1».
Сохраним полученные изменения и перейдем в режим таблицы. Давайте заведем здесь произвольные даты, выберем 21 ноября, здесь выберем 20 (дата 2 всегда больше дата 1).
Выберем 21 получим такую же ошибку, выберем 22: ошибки нет. Если вы хотите более подробно рассмотреть основные свойства полей таблицы базы данных, то ссылку на этот урок ищите в описании под этим видео. Друзья, надеюсь вы теперь знаете как побороть ошибку: Невозможно использовать несколько столбцов в ограничении CHECK уровня столбца.
Также не забываете, что у нас есть канал, где собрано более 100 уроков, которые помогут вам разобраться в программе Microsoft Access.
Правила проверки позволяют выполнять проверку данных по мере их ввода в базы данных Access для настольных систем. Для правильного форматирования правил вы можете использовать построитель выражений. Правила проверки можно задавать в конструкторе таблиц или в режиме таблицы. В Access существуют правила проверки трех типов.
1. Правило проверки поля . Это правило можно использовать для определения условий, которым должны соответствовать все допустимые значения полей. Не указывайте текущее поле в качестве части правила, если вы не используете это поле в функции. Для ограничения типов символов, которые можно вводить в поле, удобно использовать маску ввода. Например, для полей даты можно задать правило проверки, запрещающее указывать прошедшие даты.
Краткие примеры
Запрет прошедших дат: >=Date()
Общепринятый формат эл. почты: Is Null OR ((Like «*?@?*.?*») AND (Not Like «*[ ,;]*»))
Число не больше пяти: <=5
Неотрицательное значение в поле валюты: >=0
Ограничения числа знаков в строке: Len([StringFieldName])<100
2. Правило проверки записи . Это правило можно использовать для определения условий, которым должны соответствовать все допустимые записи. С помощью него вы можете сравнивать значения в разных полях. Например, для записи с двумя полями дат можно потребовать, чтобы значения одного поля всегда предшествовали значениям другого поля (то есть чтобы дата начала предшествовала дате окончания).
Краткие примеры
Проверка того, что дата окончания не предшествует дате начала: [Дата окончания]>=[Дата начала]
Ввод даты назначения, которая должна быть не позднее 30 дней с даты заказа: [Дата назначения]<=[Дата заказа]+30
3. Проверка в форме . Свойство Правило проверки элемента управления формы можно использовать для определения условий, которым должны соответствовать все данные, вводимые в этот элемент. Свойство Правило проверки элемента управления работает аналогично правилу проверки поля. Обычно правило проверки в форме используется вместо правила проверки поля, если оно относится только к данной форме, а не ко всей таблице, независимо от места использования.
В этой статье
-
Обзор
-
Добавление правила проверки в таблицу
-
Проверка имеющихся данных на соответствие новому правилу проверки
-
Добавление правила проверки в элемент управления формы
-
Справочная информация о правилах проверки
Общие сведения
В этой статье описывается, как применять правила и текст проверки к полям таблицы и элементам управления формы. Правила проверки позволяют ограничить ввод данных в поля таблицы и элементы управления формы (например, текстовые поля). Текст проверки отображается для подсказки, если пользователь вводит недопустимые данные.
После ввода данных Access проверяет их на соответствие правилу проверки. Если данные недопустимы, отобразится сообщение.
В Access есть несколько способов ограничения ввода данных.
-
Типы данных .Каждое поле таблицы имеет тип данных, который ограничивает возможности ввода для пользователей. Например, в поле с типом данных «Дата/время» можно ввести только дату и время, в поле с типом данных «Денежный» — только денежные данные и т. д.
-
Свойства поля .Некоторые свойства поля ограничивают ввод данных. Например, свойство Размер поля ограничивает количество вводимых данных.
Можно также использовать свойство Правило проверки, чтобы ограничить ввод строго определенными значениями, и свойство Сообщение об ошибке, чтобы предупреждать пользователей об ошибках. Например, правило >100 And <1000 в свойстве Правило проверки требует ввода значений между 100 и 1000. Правило [ДатаОкончания]>=[ДатаНачала] требует, чтобы вводимая дата окончания совпадала с датой начала либо следовала за ней. Текст типа «Введите значения в диапазоне от 100 до 1000» или «Введите дату окончания, которая не предшествует дате начала», указанный в свойстве Сообщение об ошибке, сообщит пользователям о допущенной ошибке и о том, как ее исправить.
-
Маски ввода .Маски ввода можно использовать для проверки данных, если требуется, чтобы пользователи вводили значения в определенном формате. Например, с помощью маски ввода можно разрешить вводить даты только в европейском формате (например, 2007.04.14).
Эти методы проверки данных можно использовать как вместе, так и в отдельности. Типы данных являются обязательными и предоставляют наиболее распространенные типы проверки данных.
Дополнительные сведения о типах данных, размерах полей и масках ввода см. в статье Введение в использование типов данных и свойств полей.
Типы правил проверки
Можно создать два основных типа правил проверки.
-
Правило проверки поля .Это правило используется для проверки введенного значения при переходе к другому полю. Предположим, имеется поле даты, и для свойства Правило проверки задано значение >=#01.01.2010#. Это правило требует, чтобы пользователи вводили дату не ранее 1 января 2010 года. Если указать дату ранее 2010 года, вы не сможете перейти к другому полю в Access, пока не исправите ошибку.
-
Правило проверки записи .Это правило используется для управления сохранением записи (строки в таблице). В отличие от правила проверки поля, для правила проверки записи используются ссылки на другие поля той же таблицы. Правило проверки записи создается, если требуется сравнить значения в разных полях. Предположим, вам требуется доставить товар в течение 30 дней, и в случае если товар не будет доставлен в этот срок, необходимо возместить клиенту убытки. Можно задать правило проверки [Срок]<=[ДатаЗаказа]+30, чтобы предупредить ввод слишком поздней даты доставки заказа (значение в поле «Срок»).
Если вам непонятен синтаксис правил проверки, см. сведения о синтаксисе и некоторые примеры правил проверки в разделе Данные, которые можно ввести в правило проверки.
Применение правил проверки
Можно задавать правила проверки для полей таблиц и элементов управления в формах. Заданные правила проверки для таблиц применяются также при импорте данных. Чтобы добавить правила проверки в таблицу, откройте нужную таблицу и используйте команды на вкладке Поля ленты. Чтобы добавить правила проверки в форму, откройте форму в режиме макета и добавьте эти правила в свойства отдельных элементов управления.
Из инструкций, приведенных в разделе Добавление правила проверки в таблицу, вы узнаете, как добавлять правила проверки в поля таблицы. А в разделе Добавление правила проверки для элемента управления формы, который вы найдете ниже в этой статье, описано, как добавлять правила в свойства отдельных элементов управления.
Данные, которые можно ввести в правило проверки
Правила проверки могут содержать выражения — функции, возвращающие единственное значение. Выражение можно использовать для выполнения вычислений, обработки знаков или проверки данных. Выражение правила проверки выполняет проверку данных. Например, может проверять наличие одного значения из ряда, например «Токио» OR «Москва» OR «Париж» OR «Хельсинки» . Выражения также могут выполнять математические операции. Например, выражение <100 требует ввода значений, меньших 100. Выражение ([ДатаЗаказа] — [ДатаДоставки]) вычисляет количество дней от даты размещения заказа до даты его исполнения.
Дополнительные сведения о выражениях см. в статье Создание выражений.
К началу страницы
Добавление правила проверки в таблицу
В таблицу можно добавлять правила проверки поля и проверки записи. Правило проверки поля проверяет данные, введенные в поле, и применяется при переходе к следующему полю. Правило проверки записи проверяет данные, введенные в одно или несколько полей, и применяется при переходе к следующей записи. Обычно правило проверки записи сравнивает значения нескольких полей.
Примечания: Правила проверки не поддерживаются в таких типах полей:
-
Счетчик
-
Объект OLE
-
Вложение
-
Код репликации
Создание правила проверки поля
-
Выберите поле, которое требуется проверить.
-
На вкладке Поля в группе Проверка поля нажмите кнопку Проверка и выберите пункт Правило проверки поля.
-
Создайте правило проверки с помощью построителя выражений. Дополнительные сведения об использовании построителя выражений см. в статье Использование построителя выражений.
Создание сообщения для отображения при вводе недопустимых данных
-
Выберите поле, для которого требуется создать сообщение на случай ввода недопустимых значений. Поле уже должно содержать правило проверки.
-
На вкладке Поля в группе Проверка поля нажмите кнопку Проверка и выберите пункт Сообщение проверки поля.
-
Введите соответствующее сообщение. Например, для правила проверки >10 можно ввести сообщение Введите значение больше 10.
Примеры правил проверки поля и сообщений см. в разделе Справочная информация о правилах проверки.
Создание правила проверки записи
-
Откройте таблицу, в которой требуется выполнить проверку записей.
-
На вкладке Поля в группе Проверка поля нажмите кнопку Проверка и выберите пункт Правило проверки поля.
-
Создайте правило проверки с помощью построителя выражений. Дополнительные сведения об использовании построителя выражений см. в статье Использование построителя выражений.
Создание сообщения для отображения при вводе недопустимой записи
-
Откройте таблицу, для которой требуется создать сообщение на случай ввода недопустимых значений. Таблица уже должна содержать правило проверки.
-
На вкладке Поля в группе Проверка поля нажмите кнопку Проверка и выберите пункт Сообщение о проверке записи.
-
Введите соответствующее сообщение. Например, для правила проверки [ДатаНачала]<[ДатаОкончания] можно ввести сообщение «Дата начала должна предшествовать дате окончания».
К началу страницы
Проверка имеющихся данных на соответствие новому правилу проверки
При добавлении правила проверки в существующую таблицу может потребоваться применить правило для проверки всех имеющихся данных на допустимость.
-
Откройте таблицу для проверки в режиме конструктора.
На вкладке Конструктор в группе Сервис нажмите кнопку Проверка условий.
-
Нажмите кнопку Да, чтобы закрыть сообщение и начать проверку.
-
Если будет предложено сохранить таблицу, нажмите кнопку Да.
-
В процессе работы могут выводиться и другие предупреждения. Прочтите инструкции в каждом из них и нажмите соответствующие кнопки Да или Нет, чтобы завершить или прекратить проверку.
К началу страницы
Добавление правила проверки в элемент управления формы
Можно использовать свойства элементов управления Правило проверки и Сообщение об ошибке для проверки данных, вводимых в элемент управления, и предупреждения пользователей о вводе недопустимых данных.
Совет: При автоматическом создании формы из таблицы с помощью одной из команд в группе «Формы» на ленте все проверки поля, имеющиеся в базовой таблице, наследуются соответствующими элементами управления в форме.
Элемент управления и поле таблицы, с которым он связан, могут иметь разные правила проверки. Это позволяет при необходимости установить для формы большее количество ограничений, чем для таблицы. В этом случае сначала будет применяться правило формы, а затем — правило таблицы. Если для таблицы установлено больше ограничений, чем для формы, приоритет отдается правилам, заданным для поля таблицы. Если правила являются взаимоисключающими, ввод каких-либо данных будет невозможен.
Предположим, что к полю даты в таблице применено следующее правило:
<#01.01.2010#
А затем к элементу управления формы, связанному с этим полем данных, применено другое правило:
>=#01.01.2010#
Таким образом, в поле данных необходимо вводить значения, предшествующие 2010 году, а в элементе управления формы — не ранее этого года. Согласно этим правилам нельзя ввести никакую дату.
Создание правила проверки для элемента управления
-
Щелкните правой кнопкой мыши форму, которую требуется изменить, и выберите пункт Режим макета.
-
Щелкните правой кнопкой мыши элемент управления, который требуется изменить, и выберите пункт Свойства для отображения окна свойств.
-
Откройте вкладку Все и введите правило проверки в поле свойства Правило проверки.
Совет: Нажмите кнопку Построить для запуска построителя выражений.
Дополнительные сведения об использовании построителя выражений см. в статье Использование построителя выражений.
-
Введите сообщение об ошибке в поле свойства Сообщение об ошибке.
К началу страницы
Справочная информация о правилах проверки
В правилах проверки используется синтаксис выражений Access. Дополнительные сведения о выражениях см. в статье Введение в использование выражений.
Примеры правил и текста проверки
|
Правило проверки |
Текст проверки |
|
<>0 |
Введите значение, отличное от нуля. |
|
>=0 |
Значение не должно быть отрицательным. -или- Введите положительное число. |
|
0 or >100 |
значение должно быть равно 0 либо быть больше 100. |
|
BETWEEN 0 AND 1 |
Введите значение со знаком процента. (Для полей с числовыми значениями процентов.) |
|
<#01.01.2007# |
Введите дату, предшествующую 2007 году. |
|
>=#01.01.2007# AND <#01.01.2008# |
Укажите дату в 2007 году. |
|
<Date() |
Дата рождения не может быть в будущем. |
|
StrComp(UCase([Фамилия]), |
Заполните поле «Фамилия» прописными буквами. |
|
>=Int(Now()) |
Ведите текущую дату. |
|
М Or Ж |
Введите «М» для мужского пола, «Ж» — для женского. |
|
LIKE «[A-Z]*@[A-Z].com» OR «[A-Z]*@[A-Z].net» OR «[A-Z]*@[A-Z].org» |
Введите допустимый адрес электронной почты, оканчивающийся на .com, .net или .org. |
|
[Срок]<=[ДатаЗаказа]+30 |
Заказ должен быть исполнен не позже чем через 30 дней. |
|
[ДатаОкончания]>=[ДатаНачала] |
Дата окончания не должна предшествовать дате начала. |
Примеры синтаксиса для основных операторов правил проверки
|
Оператор |
Функция |
Пример |
|
NOT |
Проверяет наличие противоположных значений. Используется перед любым оператором сравнения, кроме IS NOT NULL. |
NOT > 10 (то же, что и <=10). |
|
IN |
Проверяет наличие значений, равных существующим элементам списка. Значение, используемое в сравнении, должно быть списком значений, разделенных запятыми и заключенных в круглые скобки. |
IN («Токио», «Париж», «Москва») |
|
BETWEEN |
Проверяет принадлежность к диапазону значений. Необходимо использовать два значения для сравнения — верхний и нижний пределы — и разделять эти значения с помощью разделителя AND. |
BETWEEN 100 AND 1000 (то же, что и >=100 AND <=1000) |
|
LIKE |
Сопоставляет образец строки с текстовым полем или полем МЕМО. |
LIKE «Гео*» |
|
IS NOT NULL |
Требует ввода значения в поле. Результат такой же, как при задании для свойства Обязательное поле значения Да. Но если свойство Обязательное поле включено, а пользователю не удается ввести значение, в Access отображается непонятное сообщение об ошибке. Удобнее использовать в базе данных оператор IS NOT NULL и ввести информативное сообщение в свойстве Текст проверки. |
IS NOT NULL |
|
AND |
Указывает, что все части правила проверки должны быть истинными. |
>= #01.01.2007# AND <=#06.03.2008# Примечание: Для объединения правил проверки можно также использовать оператор AND. Например: NOT «КНР» AND LIKE «Р*». |
|
OR |
Указывает, что некоторые (но не все) части правила проверки должны быть истинными. |
«Январь» OR «Февраль» |
|
< |
Меньше. |
|
|
<= |
Меньше или равно. |
|
|
> |
Больше. |
|
|
>= |
Больше или равно. |
|
|
= |
Равно. |
|
|
<> |
Не равно. |
Использование подстановочных знаков в правилах проверки
В правилах проверки можно использовать подстановочные знаки. Имейте в виду, что Access поддерживает два набора подстановочных знаков: ANSI-89 и ANSI-92. В этих стандартах используются различные наборы подстановочных знаков.
По умолчанию, для всех файлов формата ACCDB и MDB используется стандарт ANSI-89.
Можно изменить стандарт ANSI для базы данных на стандарт ANSI-92, выполнив следующие действия.
-
На вкладке Файл выберите пункт Параметры.
-
В диалоговом окне Параметры Access выберите пункт Конструкторы объектов.
-
В разделе Конструктор запросов в группе Синтаксис для SQL Server (ANSI 92) установите флажок эта база данных.
Дополнительные сведения об использовании подстановочных знаков и стандартах ANSI для языка SQL см. в статье Справочные сведения о подстановочных знаках в Access.
К началу страницы
Consider the following table with a constraint that’s a bit daft but simple enough to demonstrate my point. Note that, to keep things very simple, the constraint’s criteria only involve literal values. The column ID only exists because a table must have at least one column (!!) but that column is not involved in the constraint. While a little daft (hence the name) this is perfectly legal syntax and similar to adding WHERE 0 = 1 to a SELECT query to ensure it returns zero rows.
(Standard SQL DDL code, will execute in ACE/Jet’s ANSI-92 Query Mode)
CREATE TABLE Test1
(
ID INTEGER NOT NULL,
CONSTRAINT daft_1 CHECK (5 = NULL)
);
The following INSERT succeeds:
INSERT INTO Test1 (ID) VALUES (1);
This is expected behaviour. The predicate 5 = NULL should evaluate to UNKNOWN. The INSERT is ‘given the benefit of the doubt’ and succeeds. No problem there.
Consider this similar example using the IN operator:
CREATE TABLE Test2
(
ID INTEGER NOT NULL,
CONSTRAINT daft_2 CHECK (5 IN (0, 1, NULL))
);
The following INSERT fails because the constraint bites:
INSERT INTO Test2 (ID) VALUES (1);
This is unexpected behviour, by me at least. I would expect the 5 IN (0, 1, NULL) to again be evaluated as UNKNOWN and the INSERT to succeed for the same reasons as the first example.
I would expect the logic in the second example to be the same as the following third example:
CREATE TABLE Test3
(
ID INTEGER NOT NULL,
CONSTRAINT daft_3 CHECK((5 = 0) OR (5 = 1) OR (5 = NULL))
);
The following INSERT succeeds:
INSERT INTO Test3 (ID) VALUES (1);
This is expected behaviour.
I’ve tested all three examples on SQL Server and the all work as I expect i.e. all three INSERT statements succeed. In fact, examining the INFORMATION SCHEMA reveals that for the second example SQL Server as ‘helpfully’ (grrr) rewritten the constraint’s clause to replace the IN operator with
((5)=NULL OR (5)=(1) OR (5)=(0))
So, for ACE/Jet, what is ‘broken’ here: the IN operator or the CHECK constraint?
Here’s some VBA code to reproduce the problem using a NULLable column; also demonstrates that dropping the constraint allows the INSERT to succeed:
Sub TestJetInCheck()
On Error Resume Next
Kill Environ$("temp") & "\DropMe.mdb"
On Error GoTo 0
Dim cat
Set cat = CreateObject("ADOX.Catalog")
With cat
.Create _
"Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=" & _
Environ$("temp") & "\DropMe.mdb"
With .ActiveConnection
Dim Sql As String
Sql = _
"CREATE TABLE Test" & vbCr & _
"(" & vbCr & _
" ID INTEGER, " & vbCr & _
" CONSTRAINT daft_constraint " & vbCr & _
" CHECK (5 IN (0, 1, NULL))" & vbCr & _
");"
.Execute Sql
Sql = "INSERT INTO Test (ID) VALUES (1);"
On Error Resume Next
.Execute Sql
If Err.Number <> 0 Then
MsgBox Err.Description
Else
MsgBox "{{no error}}"
End If
On Error GoTo 0
.Execute "ALTER TABLE Test DROP CONSTRAINT daft_constraint;"
On Error Resume Next
.Execute Sql
If Err.Number <> 0 Then
MsgBox Err.Description
Else
MsgBox "{{no error}}"
End If
On Error GoTo 0
End With
Set .ActiveConnection = Nothing
End With
End Sub
EDIT: I just thought to try this:
SELECT NULL IN (1);
— returns NULL
SELECT 1 IN (NULL)
— returns zero i.e. FALSE