Il server SQL ignora il caso in un'espressione where

Question 1

Come faccio a costruire una query SQL (MS SQL Server) in cui la clausola "where" non fa distinzione tra maiuscole e minuscole?

SELECT * FROM myTable WHERE myField = 'sOmeVal'

Voglio che i risultati tornino ignorando il caso

Question 2

Nella configurazione predefinita di un database di SQL Server, i confronti tra stringhe non fanno distinzione tra maiuscole e minuscole. Se il database sostituisce questa impostazione (tramite l'uso di regole di confronto alternative), sarà necessario specificare il tipo di regole di confronto da utilizzare nella query.

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

Nota che le regole di confronto che ho fornito sono solo un esempio (anche se molto probabilmente funzionerà bene per te). Una descrizione più completa delle regole di confronto di SQL Server è disponibile qui .

Question 3

Di solito, i confronti tra stringhe non fanno distinzione tra maiuscole e minuscole. Se il database è configurato per le regole di confronto con distinzione tra maiuscole e minuscole, è necessario forzarne l'uso senza distinzione tra maiuscole e minuscole:

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

Question 4

Ho trovato un'altra soluzione altrove; cioè da usare

upper(@yourString)

ma tutti qui dicono che, in SQL Server, non importa perché ignora comunque il caso? Sono abbastanza sicuro che il nostro database fa distinzione tra maiuscole e minuscole.

Question 5

Le prime 2 risposte (da Adam Robinson e Andrejs Cainikovs ) sono un po 'corrette, in quanto tecnicamente funzionano, ma le loro spiegazioni sono sbagliate e quindi potrebbero essere fuorvianti in molti casi. Ad esempio, sebbene le SQL_Latin1_General_CP1_CI_ASregole di confronto funzionino in molti casi, non si dovrebbe presumere che siano le regole di confronto appropriate senza distinzione tra maiuscole e minuscole. Infatti, dato che l'OP sta lavorando in un database con un confronto case-sensitive (o possibilmente binario), sappiamo che l'OP non sta usando il confronto che è l'impostazione predefinita per così tante installazioni (specialmente quelle installate su un sistema operativo usando gli Stati Uniti l'inglese come lingua): SQL_Latin1_General_CP1_CI_AS. Certo, l'OP potrebbe essere utilizzato SQL_Latin1_General_CP1_CS_AS, ma quando si lavora conVARCHARdata, è importante non modificare la code page in quanto potrebbe portare alla perdita di dati, e ciò è controllato dalle impostazioni locali / cultura delle regole di confronto (ad esempio Latin1_General vs French vs Hebrew ecc). Si prega di vedere il punto 9 di seguito.

Le altre quattro risposte sono sbagliate a vari livelli.

Chiarirò qui tutti i malintesi in modo che i lettori possano, si spera, fare le scelte più appropriate / efficienti.

Non utilizzare UPPER(). Questo è un lavoro extra completamente inutile. Usa una COLLATEclausola. In entrambi i casi è necessario eseguire un confronto tra stringhe, ma using UPPER()deve anche controllare, carattere per carattere, se è presente una mappatura maiuscola, quindi modificarla. E devi farlo su entrambi i lati. L'aggiunta COLLATEindica semplicemente all'elaborazione di generare le chiavi di ordinamento utilizzando un insieme di regole diverso da quello predefinito. L'uso COLLATEè decisamente più efficiente (o "performante", se ti piace quella parola :) che usare UPPER(), come dimostrato in questo script di test (su PasteBin) .

C'è anche il problema notato da @Ceisc sulla risposta di @ Danny:

In alcune lingue, le conversioni dei casi non vengono eseguite in andata e ritorno. cioè LOWER (x)! = LOWER (UPPER (x)).

La lettera maiuscola turca "İ" è l'esempio comune.
No, le regole di confronto non sono un'impostazione a livello di database, almeno non in questo contesto. Esistono regole di confronto predefinite a livello di database e vengono utilizzate come impostazioni predefinite per le colonne modificate e di nuova creazione che non specificano la COLLATEclausola (che è probabile da cui provenga questo malinteso comune), ma non influisce direttamente sulle query a meno che tu non lo sia confrontando i valori letterali e le variabili stringa con altri valori letterali e variabili stringa oppure si fa riferimento a metadati a livello di database.
No, le regole di confronto non sono per query.
Le regole di confronto sono per predicato (cioè qualcosa di operando qualcosa) o espressione, non per query. E questo è vero per l'intera query, non solo per la WHEREclausola. Questo copre JOINs, GROUP BY, ORDER BY, PARTITION BY, ecc.
No, non convertire in VARBINARY(ad es. convert(varbinary, myField) = convert(varbinary, 'sOmeVal')) Per i seguenti motivi:
1. questo è un confronto binario, che non fa distinzione tra maiuscole e minuscole (che è ciò che questa domanda chiede)
2. se vuoi un confronto binario, usa un confronto binario. Usane uno che finisca con _BIN2se stai usando SQL Server 2008 o più recente, altrimenti non hai altra scelta che usarne uno che finisca con _BIN. Se i dati sono NVARCHAR, non importa quale locale usi poiché sono tutti uguali in quel caso, quindi Latin1_General_100_BIN2funziona sempre. Se i dati sono VARCHAR, è necessario utilizzare la stessa impostazione internazionale che i dati sono attualmente in (ad esempio Latin1_General, French, Japanese_XJIS, ecc), perché l'impostazione internazionale determina la pagina di codice che viene utilizzato, e la modifica di pagine di codice in grado di alterare i dati (ad esempio perdita di dati).
3. l'utilizzo di un tipo di dati a lunghezza variabile senza specificare la dimensione dipenderà dalla dimensione predefinita e sono disponibili due impostazioni predefinite diverse a seconda del contesto in cui viene utilizzato il tipo di dati. È 1 o 30 per i tipi di stringa. Quando viene utilizzato con CONVERT()esso, utilizzerà il valore predefinito 30. Il pericolo è che, se la stringa può superare i 30 byte, verrà troncata silenziosamente e probabilmente otterrai risultati errati da questo predicato.
4. Anche se si desidera un confronto con distinzione tra maiuscole e minuscole, le regole di confronto binarie non sono sensibili al maiuscolo / minuscolo (un altro malinteso molto comune).
No, LIKEnon fa sempre distinzione tra maiuscole e minuscole. Utilizza le regole di confronto della colonna a cui si fa riferimento o le regole di confronto del database se una variabile viene confrontata con un valore letterale stringa o le regole di confronto specificate tramite la COLLATEclausola facoltativa .
LCASEnon è una funzione di SQL Server. Sembra essere Oracle o MySQL. O forse Visual Basic?
Poiché il contesto della domanda sta confrontando una colonna con una stringa letterale, né il confronto dell'istanza (spesso denominato "server") né il confronto del database hanno alcun impatto diretto qui. Le regole di confronto vengono archiviate per ogni colonna e ogni colonna può avere regole di confronto diverse e non è necessario che tali regole di confronto siano le stesse delle regole di confronto predefinite del database o dell'istanza. Certo, le regole di confronto dell'istanza sono l'impostazione predefinita per ciò che un database appena creato utilizzerà come regole di confronto predefinite se la COLLATEclausola non è stata specificata durante la creazione del database. Allo stesso modo, le regole di confronto predefinite del database sono ciò che una colonna modificata o appena creata utilizzerà se la COLLATEclausola non è stata specificata.
È necessario utilizzare le regole di confronto senza distinzione tra maiuscole e minuscole, altrimenti le stesse delle regole di confronto della colonna. Utilizzare la seguente query per trovare le regole di confronto della colonna (modificare il nome della tabella e il nome dello schema):
```
SELECT col.*
FROM   sys.columns col
WHERE  col.[object_id] = OBJECT_ID(N'dbo.TableName')
AND    col.[collation_name] IS NOT NULL;
```
Quindi cambia semplicemente _CSessere _CI. Quindi, Latin1_General_100_CS_ASsarebbe diventato Latin1_General_100_CI_AS.

Se la colonna utilizza un confronto binario (che termina con _BINo _BIN2), trova un confronto simile utilizzando la query seguente:
```
SELECT *
FROM   sys.fn_helpcollations() col
WHERE  col.[name] LIKE N'{CurrentCollationMinus"_BIN"}[_]CI[_]%';
```
Ad esempio, supponendo che la colonna stia usando Japanese_XJIS_100_BIN2, fai questo:
```
SELECT *
FROM   sys.fn_helpcollations() col
WHERE  col.[name] LIKE N'Japanese_XJIS_100[_]CI[_]%';
```

Per maggiori informazioni su regole di confronto, codifiche, ecc., Visitare: Informazioni sulle collazioni

Question 6

No, solo l'utilizzo LIKEnon funzionerà. LIKEcerca i valori che corrispondono esattamente al modello fornito. In questo caso LIKEtroverà solo il testo "sOmeVal" e non "someval".

Una soluzione pratica è usare la LCASE()funzione. LCASE('sOmeVal')ottiene la stringa minuscola del testo: 'someval'. Se utilizzi questa funzione per entrambi i lati del confronto, funziona:

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

L'istruzione confronta due stringhe minuscole, in modo che 'sOmeVal' corrisponda a ogni altra notazione di 'someval' (ad esempio 'Someval', 'sOMEVAl' ecc.).

Question 7

Puoi forzare la distinzione tra maiuscole e minuscole, eseguendo il casting su un varbinary in questo modo:

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

Question 8

Su quale database ti trovi? Con MS SQL Server, è un'impostazione a livello di database oppure puoi sovrascriverla per query con la parola chiave COLLATE.