SQL-сервер игнорирует регистр в выражении where

Question

Как создать SQL-запрос (MS SQL Server), где " где " предложение нечувствительно к регистру?

SELECT * FROM myTable WHERE myField = 'sOmeVal'

Я хочу, чтобы результаты возвращались без учета дела

Answer 1

В конфигурации по умолчанию базы данных SQL Server сравнения строк не чувствительны к регистру. Если ваша база данных переопределяет этот параметр (с помощью альтернативного сопоставления), вам необходимо указать тип сортировки, который будет использоваться в вашем запросе.

SELECT * FROM myTable WHERE myField = 'sOmeVal' COLLATE SQL_Latin1_General_CP1_CI_AS

Обратите внимание, что приведенная мною сортировка является лишь примером (хотя, скорее всего, она вам подойдет). Более подробное описание параметров сортировки SQL Server можно найти здесь .

Answer 2

Обычно сравнения строк не чувствительны к регистру. Если ваша база данных настроена на сортировку с учетом регистра, вам нужно принудительно использовать регистр без учета регистра:

SELECT balance FROM people WHERE email = 'billg@microsoft.com'
  COLLATE SQL_Latin1_General_CP1_CI_AS 

Answer 3

Я нашел другое решение в другом месте; то есть использовать

upper(@yourString)

но все здесь говорят, что в SQL Server это не имеет значения, потому что игнорирует регистр? Я уверен, что наша база данных чувствительна к регистру.

Answer 4

Нет, только использование LIKE не будет работать. LIKE ищет значения, точно соответствующие вашему заданному шаблону. В этом случае LIKE найдет только текст «sOmeVal», а не «someval».

Практическое решение использует функцию LCASE () . LCASE ('sOmeVal') получает строчную строку вашего текста: 'someval'. Если вы используете эту функцию для обеих сторон вашего сравнения, она работает:

SELECT * FROM myTable WHERE LCASE (myField) LIKE LCASE ('sOmeVal')

Оператор сравнивает две строчные буквы, так что ваш sOmeVal будет соответствовать всем другим обозначениям someval (например, Someval, sOMEVAl и т. д.).

Answer 5

Лучшие 2 ответа (от Адама Робинсона и Андрей Каиников ) своего рода, с правильной точки зрения, технически работают, но их объяснения неверны и во многих случаях могут вводить в заблуждение. Например, хотя сортировка SQL_Latin1_General_CP1_CI_AS будет работать во многих случаях, ее не следует рассматривать как соответствующую сортировку без учета регистра. Фактически, учитывая, что OP работает в базе данных с сортировкой с учетом регистра (или, возможно, двоичным кодом), мы знаем, что OP не использует параметры сортировки, которые используются по умолчанию для столь многих установок (особенно любых, установленных в ОС). используя американский английский в качестве языка): SQL_Latin1_General_CP1_CI_AS . Конечно, OP может использовать SQL_Latin1_General_CP1_CS_AS , но при работе с данными VARCHAR важно не изменять кодовую страницу, так как это может привести к к потере данных, и это контролируется языком / культурой сопоставления (то есть Latin1_General против французского языка против иврита и т. д.). Пожалуйста, смотрите пункт № 9 ниже.

Остальные четыре ответа в разной степени неверны.

Я проясню все недоразумения, чтобы читатели могли сделать наиболее подходящий / эффективный выбор.

<Ол>

Не используйте UPPER () . Это совершенно ненужная дополнительная работа. Используйте предложение COLLATE . Сравнение строк необходимо выполнять в любом случае, но использование UPPER () также должно проверять, символ за символом, чтобы увидеть, есть ли отображение в верхнем регистре, а затем изменить его. И вам нужно сделать это с обеих сторон. Добавление COLLATE просто направляет обработку для генерации ключей сортировки с использованием набора правил, отличного от того, который использовался по умолчанию. Использование COLLATE определенно более эффективно (или " performancemant " ;, если вам нравится это слово :), чем использование UPPER () , как доказано в этом тестовый скрипт (на PasteBin) .

Существует также проблема , отмеченная @Ceisc в @ Ответ Дэнни:

  

В некоторых языках преобразования не происходят в обе стороны. то есть НИЖНЯЯ (x)! = НИЖНЯЯ (ВЕРХНЯЯ (x)).

Турецкая прописная буква " İ " это общий пример.

Нет, сортировка не является настройкой всей базы данных, по крайней мере, не в этом контексте. Существует сопоставление по умолчанию на уровне базы данных, и оно используется в качестве значения по умолчанию для измененных и вновь создаваемых столбцов, в которых не указано предложение COLLATE (что, вероятно, является источником этого распространенного заблуждения), но оно не влияет непосредственно на запросы, если вы не сравниваете строковые литералы и переменные с другими строковыми литералами и переменными или не используете метаданные уровня базы данных.

Нет, сопоставление не для запроса.

Сопоставления - это на предикат (т.е. что-то операнд что-то) или выражение, а не на запрос. И это верно для всего запроса, а не только для предложения WHERE . Это включает в себя СОЕДИНЕНИЯ, ГРУППЫ BY, ORDER BY, PARTITION BY и т. Д.

Нет, не конвертировать в VARBINARY (например, convert (varbinary, myField) = convert (varbinary, 'sOmeVal') ) по следующим причинам: <Ол>

это бинарное сравнение, которое не учитывает регистр (что и задает этот вопрос)

если вы хотите двоичное сравнение, используйте двоичное сопоставление. Используйте тот, который заканчивается на _BIN2 , если вы используете SQL Server 2008 или новее, иначе у вас нет другого выбора, кроме как использовать тот, который заканчивается на _BIN . Если данные NVARCHAR , то не имеет значения, в какой локали вы используете

Answer 6

Вы можете принудительно ввести регистр символов, приведя к типу varbinary следующим образом:

SELECT * FROM myTable 
WHERE convert(varbinary, myField) = convert(varbinary, 'sOmeVal')

Answer 7

В какой базе данных вы находитесь? В MS SQL Server это параметр для всей базы данных, или вы можете переопределить его для каждого запроса с помощью ключевого слова COLLATE.