Попробуйте изменить LIKE на ALIKE и ваши символы подстановки с * на %.
Модуль доступа к базе данных (Jet, ACE и т. Д.) Имеет два режима запросов ANSI , каждый из которых использует различные символы подстановки для LIKE:
OLE DB всегда использует ANSI-92 Query Mode.
DAO всегда использует ANSI-89 Query Mode.
Интерфейс доступа может быть настроен на использование одного или другого.
Однако при использовании ключевого слова ALIKE подстановочный знак всегда равен % независимо от режима запросов ANSI.
Рассмотрим бизнес-правило, согласно которому элемент данных должен состоять ровно из восьми числовых символов. Скажем, я реализовал правило следующим образом:
CREATE TABLE MyStuff
(
ID CHAR(8) NOT NULL,
CHECK (ID NOT LIKE '%[!0-9]%')
);
Неизбежно, что я бы использовал % в качестве подстановочного символа, поскольку тип данных Access CHAR и ограничения CHECK могут быть созданы только в режиме запроса ANSI-92.
Однако кто-то может получить доступ к базе данных, используя DAO, который всегда использует ANS-89 Query Mode, и символ % будет считаться литералом, а не «специальным» символом, и может быть выполнен следующий код:
INSERT INTO MyStuff (ID) VALUES ('%[!0-9]%');
вставка будет успешной, и моя целостность данных будет проверена: (
То же самое можно сказать, используя LIKE и * в правиле проверки, созданном в режиме запросов ANSI-89, и тех, кто подключается с помощью ADO, который всегда использует режим запросов ANSI-92, и вставляет a * символ, в котором символ * не должен быть.
Насколько я знаю, нет способа указать, какой режим запросов ANSI используется для доступа к базе данных Access. Поэтому я думаю, что весь SQL должен быть закодирован, чтобы вести себя согласованно, независимо от выбранного пользователем режима запросов ANSI.
Обратите внимание, что не так уж сложно кодировать оба кода, используя LIKE с приведенным выше примером, например.
CHECK (
ID NOT LIKE '%[!0-9]%'
AND ID NOT LIKE '*[!0-9]*'
)
... или вообще избегать подстановочных знаков, например
CHECK (ID LIKE '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]')
Однако использование ALIKE приведет к уменьшению количества подробного кода, т. Е. Будет проще для читателя и, следовательно, проще в обслуживании.
Кроме того, когда приходит время портировать на продукт SQL, совместимый со стандартами SQL, ALIKE также хорошо переносится, т. Е. Преобразование ключевого слова ALIKE в LIKE - это все, что требуется. При анализе данного предиката SQL гораздо проще найти одно ключевое слово LIKE, чем найти все множественные экземпляры символа * в текстовых литералах. Помните, что «переносимый» не означает «код будет выполняться« как есть »; скорее это мера того, насколько легко перемещать код между платформами (и имейте в виду, что перемещение между версиями одного и того же продукта - это порт, например, Jet 4.0 для ACE - это порт, потому что безопасность на уровне пользователя больше не работает, DECIMAL значения сортируются по-разному и т. д.).