SQL Server ignorieren Fall in einem in dem Ausdruck

StackOverflow https://stackoverflow.com/questions/1224364

Frage

Wie konstruiere ich eine SQL-Abfrage (MS SQL Server), wo die "where" -Klausel ist Groß- und Kleinschreibung? 

SELECT * FROM myTable WHERE myField = 'sOmeVal'

Ich mag die Ergebnisse, den Fall wieder zu ignorieren

War es hilfreich?

Lösung

In der Standardkonfiguration einer SQL Server-Datenbank, Zeichenfolgenvergleichen sind Groß- und Kleinschreibung. Wenn Ihre Datenbank diese Einstellung hat Vorrang vor (durch die Verwendung eines alternativen Sortierungs), dann werden Sie müssen angeben, welche Art von Sortierung in Ihrer Anfrage zu verwenden. 

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

Beachten Sie, dass die Sortierung I vorgesehen ist nur ein Beispiel (obwohl es mehr als wahrscheinlich Funktion gut für Sie). Eine gründlichere Überblick über SQL Server-Sortierungen können hier .

Andere Tipps

Normalerweise String-Vergleiche sind Groß- und Kleinschreibung. Wenn Ihre Datenbank konfiguriert ist, sensitive Sortierung zu Fall, müssen Sie zwingen, ein Groß- und Kleinschreibung einer zu verwenden: 

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

fand ich eine andere Lösung an anderer Stelle; das heißt, zu verwenden, 

upper(@yourString)

, aber jeder hier sagt, dass in SQL Server, es spielt keine Rolle, weil es sowieso Fall ignoriert wird? Ich bin mir ziemlich sicher, dass unsere Datenbank der Groß- und Kleinschreibung.

Nein, nur mit LIKE wird nicht funktionieren. LIKE sucht Werten entsprechen genau Ihr vorgegebenes Muster. In diesem Fall würde LIKE nur der Text 'sOmeVal' gefunden und nicht 'someval'.

Eine pracitcable Lösung wird mit der LCASE() Funktion. LCASE('sOmeVal') erhält den Klein Zeichenfolge des Textes: ‚someval‘. Wenn Sie diese Funktion nutzen zu beiden Seiten des Vergleichs, es funktioniert:

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

Die Anweisung vergleicht zwei Klein Strings, so dass Ihre 'sOmeVal' wird jede andere Schreibweise von 'someval' entsprechen (z 'Someval', 'sOMEVAl' usw.).

Die Top 2 Antworten (von Adam Robinson und Andrejs Cainikovs ) sind irgendwie, sorta richtig, dass sie technisch funktionieren, aber ihre Erklärungen sind falsch und so in vielen Fällen irreführend sein könnte. Während zum Beispiel der SQL_Latin1_General_CP1_CI_AS Sortierung in vielen Fällen funktionieren wird, soll nicht davon ausgegangen werden, die entsprechende Groß- und Kleinschreibung Sortierung sein. In der Tat gegeben, dass die OP in einer Datenbank mit Groß- und Kleinschreibung (oder möglicherweise binär) Sortierungs arbeiten, wissen wir, dass die OP nicht die Sortierung verwendet, die der Standard für so viele Anlagen (vor allem jede auf einem OS installiert mit US-Englisch als Sprache): SQL_Latin1_General_CP1_CI_AS. Sicher, die OP könnte sein SQL_Latin1_General_CP1_CS_AS verwenden, aber wenn sie mit VARCHAR Daten arbeiten, ist es wichtig, nicht die Codepage zu ändern, da es zu Datenverlust führen kann, und dass durch die locale / Kultur gesteuert wird die Sortierung (dh Latin1_General vs Französisch vs Hebräisch usw.). Bitte siehe Punkt 9 unten.

Die anderen vier Antworten sind falsch in unterschiedlichem Ausmaß.

Ich werde all die Missverständnisse hier klären, so dass Leser hoffentlich die am besten geeigneten / effiziente Entscheidungen treffen können.

  1. Sie nicht UPPER() verwenden. Das ist völlig unnötig zusätzliche Arbeit. Verwenden Sie eine COLLATE Klausel. Ein String-Vergleich muss in jedem Fall durchgeführt werden, wobei jedoch UPPER() hat auch Zeichen für Zeichen, um zu überprüfen, um zu sehen, ob es ein Großbuchstaben-Mapping ist, und ändern Sie es dann. Und Sie müssen dies auf beiden Seiten tun. Hinzufügen COLLATE leitet einfach die Verarbeitung des Sortierschlüssel mit einem anderen Satz von Regeln zu erzeugen, als es standardmäßig gehen wurde. COLLATE verwendet, ist auf jeden Fall effizienter (oder „performant“, wenn Sie wie das Wort :) als UPPER() verwenden, wie sie in dieser Test Skript (auf Pastebin) .

    Es gibt auch das Problem von @Ceisc notierte am @ Dannys Antwort:

      

    In einigen Sprachen Fall Umwandlungen nicht Round-Trip. das heißt LOWER (x)! = LOWER (UPPER (x)).

    Die türkischen Großbuchstaben "I" das gängige Beispiel ist.

  2. Nein, Sortierung keine Datenbank weite Einstellung ist, zumindest nicht in diesem Zusammenhang. Es ist eine Datenbank-Ebene Standardsortierung, und es wird als Standard für geänderte und neu erstellte Spalten verwendet, die die COLLATE Klausel nicht angeben (was wahrscheinlich ist, wo dieses weit verbreitete Missverständnis herkommt), aber es funktioniert nicht Abfragen auswirken direkt, wenn Sie Stringliterale und Variablen auf andere Stringliterale und Variablen zu vergleichen, oder Sie verweisen auf Datenbankebene Meta-Daten.

  3. Nein, Sortierung ist nicht pro Abfrage.

  4. Sortierungen sind pro Prädikat (das heißt etwas Operanden etwas) oder Ausdruck, nicht pro Abfrage. Und das gilt für die gesamte Abfrage, nicht nur die WHERE Klausel. Dies umfasst JOIN, GROUP BY, ORDER BY, PARTITION BY, etc.

  5. Nein, nicht konvertieren (e.g.VARBINARY) aus den folgenden Gründen convert(varbinary, myField) = convert(varbinary, 'sOmeVal'):

    1. , die ein binärer Vergleich ist, die nicht Groß- und Kleinschreibung ist (das ist, was diese Frage ist zu fragen)
    2. , wenn Sie einen binären Vergleich wollen, verwenden Sie eine binäre Sortierung. Verwenden Sie eine, die mit _BIN2 endet, wenn Sie SQL Server 2008 oder höher verwenden, sonst haben Sie keine andere Wahl, als eine zu verwenden, die mit _BIN endet. Wenn die Daten NVARCHAR ist dann spielt es keine Rolle, welche locale Sie verwenden, da sie alle in diesem Fall gleich sind, also Latin1_General_100_BIN2 immer funktioniert. Wenn die Daten VARCHAR ist, müssen Sie die gleiche locale, dass der d verwendenata ist derzeit in (z.B. Latin1_General, French, Japanese_XJIS, usw.), da die locale die Codeseite bestimmt, die verwendet wird, und den Code zu ändern Seiten können die Daten (d.h. Datenverlust) verändern.
    3. mit einem mit variabler Länge Datentyp, ohne die Größe Angabe wird auf der Standardgröße verlassen, und es gibt zwei unterschiedliche Standardwerte je nach Kontext, wo der Datentyp verwendet wird. Es ist entweder 1 oder 30 für String-Typen. Wenn mit CONVERT() verwendet wird es den 30 Standardwert verwenden. Die Gefahr ist, wenn die Zeichenfolge mehr als 30 Bytes sein kann, wird es still abgeschnitten werden und Sie werden wahrscheinlich falsche Ergebnisse dieses Prädikat erhalten.
    4. Auch wenn Sie Groß- und Kleinschreibung Vergleich wollen, binäre Sortierungen sind nicht case-sensitive (ein weiterer sehr verbreiteter Irrtum).

  6. Nein, das ist nicht immer LIKE Fall empfindlich. Es verwendet die Sortierung der Spalte verwiesen wird, oder die Sortierung der Datenbank, wenn eine Variable im Vergleich zu einem String-Literal oder die Sortierung über die optionale COLLATE-Klausel angegeben.

  7. LCASE ist keine SQL Server-Funktion. Es scheint entweder Oracle oder MySQL zu sein. Oder möglicherweise Visual Basic?

  8. Da der Kontext der Frage ist eine Spalte zu einem Stringliteral Vergleich, weder die Sortierung der Instanz (oft bezeichnet als „Server“) noch die Sortierung der Datenbank hat jeden direkt Auswirkungen hier. Sortierungen sind für jede Spalte gespeichert, und jede Spalte eine andere Sortierung haben können, und diese Sortierungen brauchen nicht die gleiche wie die Datenbank der Standardsortierung oder der Instanz Sortierung zu sein. Sicher, die Instanz Sortierungs ist die Standardeinstellung für das, was eine neu erstellte Datenbank als Standard-Sortierung verwenden, wenn die COLLATE Klausel nicht angegeben wurde beim Erstellen der Datenbank. Und ebenso die Standardsortierung der Datenbank ist es, was eine veränderte oder neu erstellte Spalte verwenden, wenn die COLLATE Klausel nicht angegeben wurde.

  9. Sie sollten die Groß- und Kleinschreibung Sortierung verwenden, die ansonsten das gleiche wie die Sortierung der Spalte ist. Verwenden Sie die folgende Abfrage die Spaltensortierung zu finden (die Namen und Schemanamen der Tabelle ändern): 

    SELECT col.*
FROM   sys.columns col
WHERE  col.[object_id] = OBJECT_ID(N'dbo.TableName')
AND    col.[collation_name] IS NOT NULL;

    Dann einfach die _CS ändern werden _CI. Also, Latin1_General_100_CS_AS würde Latin1_General_100_CI_AS.

    Wenn die Spalte eine binäre Sortierung verwendet (mit der Endung _BIN oder _BIN2), dann finden eine ähnliche Zusammenstellung mithilfe der folgenden Abfrage: 

    SELECT *
FROM   sys.fn_helpcollations() col
WHERE  col.[name] LIKE N'{CurrentCollationMinus"_BIN"}[_]CI[_]%';

    Um zum Beispiel der Spalt unter der Annahme Japanese_XJIS_100_BIN2 verwenden, dies zu tun: 

    SELECT *
FROM   sys.fn_helpcollations() col
WHERE  col.[name] LIKE N'Japanese_XJIS_100[_]CI[_]%';

Für weitere Informationen über Sortierungen, Codierungen, etc. finden Sie unter: Sortierungen Info

Sie können die Groß- und Kleinschreibung zwingen, zu einem varbinary wie das Gießen: 

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

Welche Datenbank sind Sie? Mit MS SQL Server, ist es eine Datenbank weite Einstellung, oder Sie können over-ride es pro-Abfrage mit dem COLLATE Schlüsselwort.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top