Vous ne pouvez pas traduire correctement les données de caractères d’un client vers un serveur à l’aide du pilote ODBC SQL Server si la page de code client diffère de la page de code serveur

Cet article vous aide à contourner un problème qui provoque une traduction incorrecte des données client lors de l’utilisation SQL Server pilote ODBC.

Version du produit d’origine :   SQL Server
Numéro de la ko d’origine :   234748

Symptômes

Lorsque vous utilisez MDAC 2.1 ou une version ultérieure du pilote ODBC SQL Server (version 3.70.0623 ou ultérieure) ou du fournisseur OLEDB (version 7.01.0623 ou ultérieure), dans certaines circonstances, vous pouvez faire l’expérience de la traduction des données de caractères de la page de code client vers la page de code serveur, même lorsque la connexion est Autotranslation désactivée.

Cause

Autotranslation n’est pas le seul mécanisme qui peut entraîner une conversion de page de code. Le pilote ODBC SQL Server 7.0 et le fournisseur OLEDB introduisent un nouveau comportement lors de la connexion à MSDE 1.0, SQL Server 7.0 ou aux versions ultérieures de l’une ou l’autre. Toutes SQL instructions envoyées en tant qu’événement de langue sont converties en Unicode sur le client avant d’être envoyées au serveur. L’effet final est similaire à une de toutes les données qui circulent du client vers le serveur via un événement de langue, quel que soit le paramètre actuel Autotranslation Autotranslation de la connexion. Cela n’introduit aucune difficulté, sauf lorsque vous essayez de stocker des données de caractères non traduites à partir d’une page de code autre que SQL Server page de code de l’utilisateur.

Solution de contournement

Ne stockez pas les données X de la page de code dans une page de code Y SQL Server (par exemple, les données de la page de code 950 dans un serveur 1252 de la page de code). Bien que cela était possible dans certaines circonstances avec les versions précédentes de SQL Server, elle n’a toujours pas été pris en compte. Pour un chiffre de 1 252 SQL Server, tout ce qui n’est pas un caractère de 1 252 n’est pas une donnée de caractère valide. Les données de caractères non Unicode d’une autre page de code ne sont pas triées correctement et, dans le cas des données codées sur deux sur deux caractères (DBCS), SQL Server ne reconnaît pas correctement les limites des caractères. Cela peut entraîner des problèmes importants.

Le meilleur choix pour la page SQL Server code est la page de code des clients qui accèderont au serveur.

Le serveur et le client peuvent avoir des pages de code différentes, mais vous devez vous assurer que la traduction automatique est activée sur le client afin que vous receviez correctement la traduction des données vers et depuis la page de code du serveur dans tous les cas.

Si votre serveur doit stocker des données à partir de plusieurs pages de code, la solution prise en charge consiste à stocker les données dans les colonnes Unicode ( NCHAR/NVARCHAR/NTEXT ).

Si votre situation nécessite que vous stockiez des données de page de code X dans une page de code SQL Server, il existe deux façons de le faire de manière fiable :

  • Stockez les données dans des colonnes BINARY/VARBINARY/IMAGE binaires ().
  • Écrivez votre application pour utiliser les appels de procédure distante (RPCs) pour toutes les SQL qui traitent des données de caractères. Les données envoyées via un événement RPC ne sont pas soumises à la conversion. Vous ne pouvez rien faire au niveau du pilote ou de la DSN pour modifier le type d’événements envoyés. L’envoi d’une commande en tant qu’événement de langage ou RPC dépend entièrement des API et de la syntaxe choisies par le programmeur lors de l’écriture de l’application.

Plus d’informations

La traduction automatique (c’est-à-dire, la case à cocher Effectuer la traduction des données de caractères dans les applications ODBC les plus récentes) convertit les données de caractères de la page de code client en page de code serveur avant d’envoyer les données au serveur, en utilisant Unicode comme support de traduction. Toutefois, le pilote ODBC 3.7 SQL Server convertit également toutes les instructions SQL envoyées en tant qu’événement de langue en Unicode avant de les placer sur le réseau, ce qui a un effet similaire à la traduction automatique, mais qui n’est pas régi par le paramètre de traduction automatique. En revanche, les données de caractères qui circulent du serveur vers les clients respectent l’indicateur de traduction automatique . Si la traduction automatique est désactivée, les données arrivent à l’application cliente avec les mêmes codes de caractères que les données sur le serveur. De même, la traduction des données pour les événements RPC de client à serveur peut être désactivée en désactivant la traduction automatique. Script simple qui montre comment le comportement affecte les événements de langue suit. Cet exemple a été exécuté à partir de l’Analyseur de requêtes sur un client de la page de code 1252 se connectant à un serveur 437 page de code :

-- 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)

Voici ce qui suit à propos de l’exemple précédent :

  • Même s’il était hors de ce lot, le code de caractère 165 (dans la page de code 1252) a été converti en Autotranslation 157 (en page de code 437). En effet, le pilote ODBC a converti la chaîne SQL en Unicode avant de l’envoyer au serveur, de sorte que le serveur a pu la convertir en caractère approprié pour le stockage dans la page de code 437.
  • Lorsque le client a mis en place un select pour récupérer les données qui avaient été stockées, le caractère 157 est arrivé non traduit au client (157 apparaît comme une zone « » sur une page de code 1252 client). En effet, la conversion abordée dans cet article s’applique uniquement aux données envoyées du client au serveur, et non du serveur au client. Les données n’ont pas été traduites car Autotranslation le paramètre est éteint.
-- 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)

Dans ce cas, le fait de revenir en arrière n’a eu aucun effet sur la traduction du client vers le serveur (c’est-à-dire que la même traduction correcte du code de caractère 165 au code de caractère 157 s’est produite), mais elle a eu un effet sur les données extraites du Autotranslation serveur. Lorsque l’instruction SELECT est exécuté cette fois (avec on), les symboles de symboles s’affichent correctement dans la page de code 1252 de l’application, car ils ont été convertis du code de caractère 157 au code de caractère 165 par le Autotranslation Autotranslation mécanisme.

Vous verrez ce comportement (conversion d’événements de langue en Unicode sur le client) lorsque vous utilisez un pilote ODBC SQL Server version 3.70 ou ultérieure et que vous vous connectez à SQL Server 7.0 ou version ultérieure. Elle ne se produit pas lorsque vous utilisez des pilotes ODBC plus anciens ou lorsque vous utilisez le pilote 3.7 pour vous connecter à SQL Server 6.5 ou une antérieure. En outre, si vous stockez vos données dans des colonnes Unicode () la conversion ne NCHAR/NVARCHAR/NTEXT sera pas un problème.

Pour plus d’informations sur la représentation des données de caractères dans SQL Server 2005, voir Character data is represented incorrectly when the code page of the client computer differs from the code page of the database in SQL Server 2005.