SQL Server-Praxis

SQL-Server-Kollationskonflikte ohne Bedeutungsänderung lösen

Prüfen Sie Datenbank-, Spalten- und tempdb-Kollationen und beheben Sie Konflikte, ohne Vergleichsregeln, Eindeutigkeit oder Indexzugriffe zu beschädigen.

Ein Join kann nach dem Wiederherstellen einer Datenbank auf einer anderen SQL-Server-Instanz plötzlich mit einem Kollationskonflikt scheitern. Einfach COLLATE hinzuzufügen kann die Ausführung reparieren und zugleich verändern, welche Datensätze zusammenpassen. Großschreibung, Akzente und Sortierreihenfolge sind Teile des Datenvertrags.

Klären Sie zuerst die Bedeutung des Schlüssels. Sind die Kundencodes abc und ABC identisch? Soll eine Namenssuche Akzente ignorieren, während die gespeicherte Schreibweise erhalten bleibt? Ohne diese fachliche Entscheidung lässt sich der technische Konflikt nicht zuverlässig lösen.

Die beteiligten Ebenen untersuchen

Server-, Datenbank- und Spalteneinstellungen sind miteinander verbunden, aber nicht austauschbar.

SELECT SERVERPROPERTY('Collation') AS ServerCollation,
       DATABASEPROPERTYEX(DB_NAME(), 'Collation') AS DatabaseCollation,
       DATABASEPROPERTYEX(N'tempdb', 'Collation') AS TempdbCollation;

SELECT name AS ColumnName, collation_name
FROM sys.columns
WHERE object_id = OBJECT_ID(N'dbo.Customers')
  AND collation_name IS NOT NULL;

Ersetzen Sie dbo.Customers durch die tatsächlich betroffene Tabelle. Einzelne Textspalten können vom Datenbankstandard abweichen. Eine wiederhergestellte Datenbank behält ihre Einstellungen, während gewöhnliche temporäre Spalten auf klassischen SQL-Server-Installationen häufig den tempdb-Standard übernehmen. Deshalb kann derselbe Prozedurtext erst nach einem Serverwechsel scheitern.

Unicode-Datentypen beseitigen Kollationsregeln nicht. nvarchar verändert die Zeichendarstellung, benötigt für Vergleiche aber weiterhin eine Kollation. Das kleine Beispiel zeigt unterschiedliche Ergebnisse durch unterschiedliche Regeln.

SELECT
 CASE WHEN N'Cafe' COLLATE Latin1_General_100_CI_AI = N'café'
      THEN 1 ELSE 0 END AS InsensitiveMatch,
 CASE WHEN N'Cafe' COLLATE Latin1_General_100_CS_AS = N'café'
      THEN 1 ELSE 0 END AS SensitiveMatch;

InsensitiveMatch ist 1, SensitiveMatch ist 0. Der erste Vergleich ignoriert Großschreibung und Akzente; der zweite unterscheidet beides. Keine Variante ist allgemein richtig. Produktsuche und Eindeutigkeitsregel können verschiedene Anforderungen haben.

Verwenden Sie Unicode-Literale und passend typisierte Parameter für mehrsprachige Eingaben. COLLATE kann keine Zeichen wiederherstellen, die zuvor durch eine ungeeignete Nicht-Unicode-Codepage verloren gingen. Prüfen Sie daher zuerst den vollständigen Eingabepfad.

Die Übergabe an temporäre Daten abstimmen

Wenn die Zielspalte den aktuellen Datenbankstandard verwendet, kann eine temporäre Übergabespalte diesen ausdrücklich übernehmen.

-- Suitable when the target column uses the current database default.
CREATE TABLE #Incoming (
    CustomerCode nvarchar(50) COLLATE DATABASE_DEFAULT NOT NULL
);
CREATE INDEX IX_Incoming_Code ON #Incoming(CustomerCode);

Damit wird ein abweichender tempdb-Standard vermieden. Es ist jedoch keine Universallösung: Besitzt die permanente Spalte eine eigene Kollation, muss die temporäre Spalte deren tatsächlicher Regel entsprechen. Prüfen Sie auch den Datenbankkontext beim Erstellen des Objekts.

Für gelegentliche datenbankübergreifende Abfragen kann COLLATE direkt am Ausdruck angemessen sein. Wählen Sie die Regel bewusst und prüfen Sie den tatsächlichen Plan. Eine andere Kollation auf einer großen indizierten Spalte kann Umwandlungen und zusätzlichen Aufwand verursachen und die vorhandene Sortierung weniger nutzbar machen. Eine kleinere Übergabemenge passend auszurichten und zu indizieren ist oft eine bessere wiederkehrende Grenze.

LOWER oder UPPER um jeden Vergleich zu legen ersetzt diese Entscheidung nicht. Das erzeugt möglicherweise Arbeit je Zeile, erschwert Indexzugriffe und beschreibt die gewünschte Akzent- oder Sprachbehandlung weiterhin unvollständig. Geplante normalisierte Suchschlüssel brauchen eine einheitliche ausdrückliche Regel.

Einen Wechsel als Datenmigration behandeln

Eine Änderung des Datenbankstandards passt bestehende Benutzertabellenspalten nicht automatisch an. Eine vollständige Migration muss Spalten, Indizes, Einschränkungen, berechnete Ausdrücke und datenbankübergreifende Verbraucher erfassen. Auch neue Objekte und Bereitstellungsskripte müssen anschließend dieselben Vorgaben verwenden.

Suchen Sie vor dem Neuaufbau eindeutiger Indizes nach Werten, die unter der Zielregel gleich werden. Nur durch Großschreibung oder Akzente getrennte Kundenkennungen können kollidieren. Lösen Sie solche Fälle durch eine freigegebene Zuordnung, nicht durch willkürliches Entfernen einer Zeile samt ihren Beziehungen.

Eine andere Sortierung beeinflusst auch Seitennavigation und Exporte. Verwenden Sie eindeutige Zusatzschlüssel und testen Sie reale mehrsprachige Werte statt ausschließlich ASCII. Dazu gehören unterschiedliche Schreibweisen, Akzente, leere Zeichenfolgen und die tatsächlich zugelassenen Codeformate.

Prüfen Sie schließlich Ergebnis und Aufwand gemeinsam. Vergleichen Sie zugeordnete Kennungen, nicht zugeordnete Übergabezeilen und Dubletten, anschließend logische Lesezugriffe und Ausführungsplan. Die verschwundene Fehlermeldung allein bestätigt noch keine korrekte Reparatur.

Technische Referenzen: Microsoft Learn: Collation and Unicode · Microsoft Learn: COLLATE.

Frage zu diesem Artikel

Haben Sie eine Frage zu diesem Thema?

Beschreiben Sie, was Sie bewerten oder wo Sie nicht weiterkommen. Wir antworten mit einer praktischen Empfehlung.

Inquiries are not enabled in this preview.

Eine Frage zu diesem Artikel stellen