Verwalten von Datenkonvertierungen mit unterschiedlichen Client/Server-Codepages

In diesem Thema wird beschrieben, wie die Integrität von Zeichendaten gewährleistet werden kann, wenn die Datenbank die Zeichendaten nicht als Unicode-Datentypen speichert und auch die clientbasierten Anwendungen, die mit den Daten interagieren, keine Unicode-Kapazität besitzen. Unter diesen Umständen sollten die Codepage der Datenspeicherung und die Codepage der clientbasierten Anwendung identisch sein. Sind die Codepages unterschiedlich, kommt es bei der Konvertierung zwischen dem Client und dem Server möglicherweise zum Verlust von Zeichen.

Das Deaktivieren des AutoTranslate-Features des SQL Server-ODBC-Treibers, damit Daten, die von einer anderen Codepage definiert werden, vom Server eingefügt werden können, wird nicht unterstützt. Sogar wenn AutoTranslate deaktiviert ist, verhindert dies nicht die Codepageübersetzung von SQL-Sprachereignissen. Wenn Client- und Datenbankcodepage nicht übereinstimmen, wird die Codepageübersetzung im Allgemeinen auf alle Nicht-Unicode-Zeichenfolgen angewendet, die an den bzw. vom Server gesendet werden.

Diese Situation sollte nach Möglichkeit vermieden werden. Die beste Lösung besteht darin, dass ein codepagespezifischer Server nur mit Clients kommuniziert, die dieselbe Codepage verwenden. Die zweitbeste Lösung besteht darin, eine andere Codepage zu verwenden, die einen nahezu identischen Zeichensatz verwendet. Die Codepages 1252 (Latin1) und 850 (Multilingual Latin1) speichern beispielsweise nahezu dieselben Zeichensätze, sodass die meisten Zeichen ohne Datenverlust hin- und herkonvertiert werden können.

Wenn es dringend erforderlich ist, dass der Server mit Clients kommuniziert, die andere Codepages verwenden, besteht die unterstützte Lösung darin, Daten in Unicode-Spalten zu speichern. Sollte keine der bisher aufgeführten Optionen durchführbar sein, besteht eine Alternative darin, die Daten mithilfe der Datentypen binary, varbinary oder varbinary(max) in Binärspalten zu speichern. Binärdaten können jedoch nur in Binärreihenfolge sortiert oder verglichen werden. Daher bringt diese Lösung weniger Flexibilität als Zeichendaten.