Pregunta

¿Cómo construyo una consulta SQL (MS SQL Server) donde el " donde " ¿la cláusula no distingue entre mayúsculas y minúsculas?

SELECT * FROM myTable WHERE myField = 'sOmeVal'

Quiero que los resultados vuelvan ignorando el caso

¿Fue útil?

Solución

En la configuración predeterminada de una base de datos de SQL Server, las comparaciones de cadenas no distinguen entre mayúsculas y minúsculas. Si su base de datos anula esta configuración (mediante el uso de una clasificación alternativa), deberá especificar qué tipo de clasificación utilizar en su consulta.

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

Tenga en cuenta que la recopilación que proporcioné es solo un ejemplo (aunque es más que probable que funcione bien para usted). Puede encontrar un resumen más completo de las intercalaciones de SQL Server aquí .

Otros consejos

Por lo general, las comparaciones de cadenas no distinguen entre mayúsculas y minúsculas. Si su base de datos está configurada para intercalar mayúsculas y minúsculas, debe forzar el uso de mayúsculas y minúsculas:

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

Encontré otra solución en otro lugar; es decir, usar

upper(@yourString)

pero todos aquí dicen que, en SQL Server, ¿no importa porque ignora mayúsculas y minúsculas? Estoy bastante seguro de que nuestra base de datos distingue entre mayúsculas y minúsculas.

No, solo usar LIKE no funcionará. LIKE busca valores que coincidan exactamente con su patrón dado. En este caso, LIKE encontraría solo el texto 'sOmeVal' y no 'someval'.

Una solución práctica está utilizando la función LCASE () . LCASE ('sOmeVal') obtiene la cadena en minúsculas de su texto: 'someval'. Si utiliza esta función para ambos lados de su comparación, funciona:

SELECCIONAR * DE myTable DONDE LCASE (myField) LIKE LCASE ('sOmeVal')

La instrucción compara dos cadenas en minúsculas, de modo que su 'sOmeVal' coincidirá con cualquier otra notación de 'someval' (por ejemplo, 'Someval', 'sOMEVAl', etc.).

Las 2 respuestas principales (de Adam Robinson y Andrejs Cainikovs ) son más o menos correctos, ya que técnicamente funcionan, pero sus explicaciones son incorrectas y, por lo tanto, podrían ser engañosas en muchos casos. Por ejemplo, aunque la intercalación SQL_Latin1_General_CP1_CI_AS funcionará en muchos casos, no debe suponerse que es la intercalación adecuada sin distinción entre mayúsculas y minúsculas. De hecho, dado que el OP está trabajando en una base de datos con una intercalación que distingue entre mayúsculas y minúsculas (o posiblemente binarias), sabemos que el OP no está utilizando la intercalación que es la predeterminada para tantas instalaciones (especialmente cualquiera instalada en un SO usando el inglés de EE. UU. como idioma): SQL_Latin1_General_CP1_CI_AS . Claro, el OP podría estar usando SQL_Latin1_General_CP1_CS_AS , pero cuando se trabaja con datos de VARCHAR , es importante no cambiar la página de códigos ya que podría conducir a la pérdida de datos, y eso está controlado por la configuración regional / cultura de la recopilación (es decir, Latin1_General vs French vs Hebrew, etc.). Consulte el punto 9 a continuación.

Las otras cuatro respuestas son incorrectas en diversos grados.

Aclararé todos los malentendidos aquí para que los lectores puedan tomar las decisiones más apropiadas / eficientes.

  1. No use UPPER () . Eso es un trabajo extra completamente innecesario. Use una cláusula COLLATE . En cualquier caso, se debe hacer una comparación de cadenas, pero el uso de UPPER () también tiene que verificar, carácter por carácter, para ver si hay una asignación en mayúsculas y luego cambiarla. Y necesitas hacer esto en ambos lados. Agregar COLLATE simplemente dirige el procesamiento para generar las claves de clasificación utilizando un conjunto de reglas diferente de lo que era por defecto. Usar COLLATE es definitivamente más eficiente (o '' performant '', si le gusta esa palabra :) que usar UPPER () , como se demuestra en este script de prueba (en PasteBin) .

    También existe el problema señalado por @Ceisc en @ La respuesta de Danny:

      

    En algunos idiomas, las conversiones de casos no son de ida y vuelta. es decir, INFERIOR (x)! = INFERIOR (SUPERIOR (x)).

    La mayúscula turca " & # 304; " es el ejemplo común.

  2. No, la recopilación no es una configuración de toda la base de datos, al menos no en este contexto. Hay una intercalación predeterminada a nivel de base de datos, y se usa como predeterminada para columnas alteradas y recién creadas que no especifican la cláusula COLLATE (que es probable de donde proviene este error común), pero no afecta las consultas directamente a menos que esté comparando literales de cadena y variables con otros literales de cadena y variables, o esté haciendo referencia a metadatos a nivel de base de datos.

  3. No, la clasificación no es por consulta.

  4. Las intercalaciones son por predicado (es decir, algo operando algo) o expresión, no por consulta. Y esto es cierto para toda la consulta, no solo para la cláusula WHERE . Esto cubre UNIÓN, GRUPO POR, ORDEN POR, PARTICIÓN POR, etc.

  5. No, no convierta a VARBINARY (por ejemplo, convert (varbinary, myField) = convert (varbinary, 'sOmeVal') ) por las siguientes razones:

    1. que es una comparación binaria, que no distingue entre mayúsculas y minúsculas (que es lo que esta pregunta está pidiendo)
    2. si quieres una comparación binaria, usa una intercalación binaria. Use uno que termine con _BIN2 si está usando SQL Server 2008 o posterior, de lo contrario, no tiene más remedio que usar uno que termine con _BIN . Si los datos son NVARCHAR , no importa en qué configuración regional utilice un

Puede forzar mayúsculas y minúsculas, emitiendo a un varbinary como ese:

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

¿En qué base de datos estás? Con MS SQL Server, es una configuración de toda la base de datos, o puede anularla por consulta con la palabra clave COLLATE.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top