Ответ 1
Измените *
на %
, так как %
- это поиск подстановочных знаков при использовании OLE DB.
SELECT * FROM MyTable WHERE [_Items] LIKE '%SPI%'
Есть ли причина, по которой
SELECT * FROM MyTable WHERE [_Items] LIKE '*SPI*'
не возвращает никаких записей с помощью OleDbAdapter.Fill(DataSet)
или OleDbCommand.ExecuteReader()
?
Когда я запускаю тот же SQL в MS Access напрямую, он возвращает ожидаемые записи. Кроме того, в том же коде, если я изменил SQL на
SELECT * FROM MyTable
возвращаются все записи.
Измените *
на %
, так как %
- это поиск подстановочных знаков при использовании OLE DB.
SELECT * FROM MyTable WHERE [_Items] LIKE '%SPI%'
Попробуйте изменить LIKE
на ALIKE
и ваши подстановочные знаки от *
до %
.
Механизм базы данных доступа (Jet, ACE, что угодно) имеет два ANSI Query Modes, каждый из которых использует разные подстановочные знаки для LIKE
:
В режиме запроса ANSI-89 используется *
В режиме запроса ANSI-92 используется %
OLE DB всегда использует ANSI-92 Query Mode. DAO всегда использует режим запросов ANSI-89. Пользовательский интерфейс доступа может быть настроен так, чтобы использовать тот или иной.
Однако при использовании ключевого слова ALIKE
символ подстановки всегда %
, независимо от режима запросов ANSI.
Рассмотрим бизнес-правило, в котором указано, что элемент данных должен состоять из ровно восьми числовых символов. Скажем, я выполнил правило следующим образом:
CREATE TABLE MyStuff
(
ID CHAR(8) NOT NULL,
CHECK (ID NOT LIKE '%[!0-9]%')
);
Неизбежно, что я использовал бы %
в качестве подстановочного символа, поскольку ограничения доступа CHAR
и CHECK
могут быть созданы только в режиме запросов ANSI-92.
Однако кто-то мог получить доступ к базе данных с помощью DAO, который всегда использует ANS-89 Query Mode, а символ %
будет считаться буквальным, а не "специальным" символом, и следующий код может быть выполнен:
INSERT INTO MyStuff (ID) VALUES ('%[!0-9]%');
вставка будет успешной, и моя целостность данных будет снята: (
То же самое можно сказать, используя LIKE
и *
в правиле проверки, созданном в режиме запросов ANSI-89, и тех, кто подключается с использованием ADO, который всегда использует ANSI-92 Query Mode, и INSERT 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
значения сортируются по-разному и т.д.).
Попробуйте преобразовать символы подстановки (*) в%
Это должно устранить проблему.
Боже, это работает! Большое спасибо.
Мне просто пришлось заменить not like criteria
на not alike criteria
.
Я делюсь своей "историей", чтобы помочь другим легче найти этот пост и спасти их от двухчасового поиска.
Хотя я связал файлы Excel 95-97 xls с базой данных Access 2010 и запускал запросы create table
и insert into
для импорта всех данных в базу данных, по какой-то странной причине запрос выбора не мог найдите строки, которые я набрал.
Я пробовал not like "something"
и not like "%something%"
без успеха - просто не работал.
L