Sie können Zeichendaten von einem Client nicht ordnungsgemäß in einen Server übersetzen, indem Sie den SQL Server ODBC-Treiber verwenden, wenn sich die Clientcodeseite von der Servercodeseite unterscheidet.

In diesem Artikel können Sie ein Problem umgehen, das bei Verwendung des SQL Server ODBC-Treibers zu einer falschen Übersetzung von Clientdaten führt.

Ursprüngliche Produktversion: SQL Server
Ursprüngliche KB-Nummer: 234748

Problembeschreibung

Bei Verwendung der MDAC 2.1- oder höher-Version des SQL Server ODBC-Treibers (Version 3.70.0623 oder höher) oder des OLEDB-Anbieters (Version 7.01.0623 oder höher) können Sie unter bestimmten Umständen eine Übersetzung von Zeichendaten von der Clientcodeseite auf die Servercodeseite erfahren, auch wenn Autotranslation sie für die Verbindung deaktiviert ist.

Ursache

Autotranslation ist nicht der einzige Mechanismus, der zu einer Konvertierung von Codeseiten führen kann. Der SQL Server 7.0 ODBC-Treiber und OLEDB-Anbieter führen ein neues Verhalten beim Herstellen einer Verbindung mit MSDE 1.0, SQL Server 7.0 oder höher in beiden Versionen ein. Alle als Sprachereignis gesendeten SQL-Anweisungen werden vor dem Senden an den Server in Unicode auf dem Client konvertiert. Der Endeffekt ähnelt einem Autotranslation aller Daten, die vom Client über ein Sprachereignis auf den Server fließen, unabhängig von der aktuellen Autotranslation Einstellung für die Verbindung. Es treten keine Schwierigkeiten auf, es sei denn, sie versuchen, nicht übersetzte Zeichendaten von einer anderen Codeseite als der Codepage von SQL Server zu speichern.

Problemumgehung

Speichern Sie keine X-Daten der Codepage in einer Codepage Y SQL Server (z. B. Codepage 950-Daten auf einem Codepage 1252-Server). Obwohl dies unter bestimmten Umständen mit früheren Versionen von SQL Server möglich war, wurde sie immer nicht unterstützt. Für einen SQL Server mit 1252 ist alles, aber ein 1252 Zeichen keine gültigen Zeichendaten. Nicht-Unicode-Zeichendaten von einer anderen Codeseite werden nicht ordnungsgemäß sortiert, und im Falle von DBCS-Daten (Dual-Byte)-Daten erkennt SQL Server keine Zeichengrenzen richtig. Es kann erhebliche Probleme verursachen.

Die beste Wahl für die Codepage von SQL Server ist die Codeseite der Clients, die auf den Server zugreifen.

Der Server und der Client verfügen möglicherweise über unterschiedliche Codeseiten, aber Sie müssen sicherstellen, dass die Autotranslation auf dem Client aktiviert ist, damit Sie in allen Fällen eine ordnungsgemäße Übersetzung von Daten in und von der Codepage des Servers erhalten.

Wenn Ihr Server Daten von mehreren Codeseiten speichern muss, besteht die unterstützte Lösung darin, die Daten in Unicode-Spalten (NCHAR/NVARCHAR/NTEXT) zu speichern.

Wenn Ihre Situation erfordert, dass Codepage X-Daten in einer Codepage Y SQL Server gespeichert werden, gibt es nur zwei Möglichkeiten, dies zuverlässig zu erledigen:

• Speichern Sie die Daten in Binärspalten (BINARY/VARBINARY/IMAGE)-Spalten.
• Schreiben Sie Ihre Anwendung, um Remoteprozeduraufrufe (REMOTE Procedure Calls, RPCs) für alle SQL-Anweisungen zu verwenden, die mit Zeichendaten umgehen. Daten, die über ein RPC-Ereignis gesendet werden, unterliegen nicht der Konvertierung. Es gibt nichts auf Der Treiber- oder DSN-Ebene, die Sie tun können, um den Typ der gesendeten Ereignisse zu ändern. Ob ein Befehl als Sprache oder RPC-Ereignis gesendet wird, hängt vollständig von den APIs und der vom Programmierer gewählten Syntax ab, wenn die Anwendung geschrieben wird.

Weitere Informationen

Die Autotranslation (d. h. die Kontrollkästchen "Übersetzung für Zeichendaten ausführen" in neueren ODBC-Anwendungen) konvertiert Zeichendaten von der Clientcodeseite in die Servercodeseite, bevor die Daten an den Server gesendet werden, wobei Unicode als Übersetzungsmedium verwendet wird. Der ODBC-Treiber 3.7 SQL Server konvertiert jedoch auch alle SQL-Anweisungen, die als Sprachereignis gesendet werden, in Unicode, bevor sie in die Leitung platziert werden, was eine Auswirkung hat, die der Autotranslation ähnelt, aber nicht von der Autotranslationseinstellung gesteuert wird. Im Gegensatz dazu respektieren Zeichendaten, die vom Server zurück an die Clients fließen, das Autotranslationsflagge; wenn die Autotranslation deaktiviert ist, werden die Daten an der Clientanwendung mit den gleichen Zeichencodes wie die Daten auf dem Server eintreffen. Ebenso kann die Übersetzung von Daten für RPC-Ereignisse vom Client zu Server deaktiviert werden, indem die Autotranslation deaktiviert wird. Ein einfaches Skript, das veranschaulicht, wie sich das Verhalten auf Sprachereignisse auswirkt. Dieses Beispiel wurde von der Abfrageanalyse auf einer Codepage 1252-Client ausgeführt, die eine Verbindung mit einem Codepage 437-Server herstellt:

-- Turn Autotranslation off here.
 USE tempdb
 GO
 CREATE TABLE t1 (c1 int, c2 char(1))
 GO

-- Enter a yen character, using the keystroke ALT-0165.
 INSERT INTO t1 VALUES (1, '¥') 
 SELECT c1, c2, ASCII (c2) FROM t1

c1 c2 
 ----------- ---- ----------- 
 1  157

(1 row(s) affected)

Im folgenden Beispiel wird Folgendes beschrieben:

• Autotranslation Obwohl es während dieses Batches deaktiviert war, wurde der Zeichencode 165 (Yen auf der Codepage 1252) in 157 (Yen in Codepage 437) konvertiert. Dies liegt daran, dass der ODBC-Treiber die SQL-Zeichenfolge vor dem Senden in Unicode konvertiert hat, sodass der Server es in das entsprechende Zeichen für den Speicher auf der Codeseite 437 konvertieren konnte.
• Wenn der Client eine SELECT ausgeführt hat, um die gespeicherten Daten abzurufen, ist das Zeichen 157 nicht übersetzt am Client angekommen (157 wird als Feld "" auf einer Codepage 1252-Client angezeigt). Dies liegt daran, dass die in diesem Artikel beschriebene Konvertierung nur für Daten gilt, die vom Client an den Server gesendet werden, nicht von dem Server zum Client. Die Daten wurden nicht übersetzt, da die Autotranslation Einstellung deaktiviert ist.

-- Turn Autotranslation back on before running the following batch.
 INSERT INTO t1 VALUES (2, '¥')
 SELECT c1, c2, ASCII (c2) FROM t1

c1 c2 
 ----------- ---- ----------- 
 1 ¥ 157
 2 ¥ 157

(2 row(s) affected)

In diesem Fall hat das Aktivieren Autotranslation keine Auswirkungen auf die Übersetzung vom Client auf den Server (d. h. die gleiche korrekte Übersetzung aus Dem Zeichencode 165 in Zeichencode 157 ist aufgetreten), hat aber auswirkungen auf die vom Server abgerufenen Daten. Wenn die SELECT-Anweisung dieses Mal ausgeführt wird (mit Autotranslation aktiviert), werden die Yen-Symbole in der Codepage 1252-Anwendung korrekt angezeigt, da sie vom Zeichencode 157 zurück in Den Zeichencode 165 durch den Autotranslation Mechanismus übersetzt wurden.

Dieses Verhalten (Konvertierung von Sprachereignissen in Unicode auf dem Client) wird angezeigt, wenn Sie sql Server ODBC-Treiber, Version 3.70 oder höher, verwenden und eine Verbindung mit SQL Server 7.0 oder höher herstellen. Es tritt nicht auf, wenn ältere ODBC-Treiber oder der 3.7-Treiber zum Herstellen einer Verbindung mit SQL Server 6.5 oder einer früheren Version verwendet wird. Wenn Sie Ihre Daten in Unicode-Spalten (NCHAR/NVARCHAR/NTEXT) speichern, ist die Konvertierung kein Problem.

Weitere Informationen dazu, wie Zeichendaten in SQL Server 2005 dargestellt werden, finden Sie unter "Falsch dargestellte Zeichendaten", wenn sich die Codepage des Clientcomputers von der Codepage der Datenbank in SQL Server 2005 unterscheidet.