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 du serveur.

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

Version du produit d’origine :   SQL Server
Numéro de la base de connaissances initiale :   234748

Symptômes

Lorsque vous utilisez la version MDAC 2,1 ou une version ultérieure du pilote ODBC SQL Server (version 3.70.0623 ou ultérieure) ou le fournisseur OLEDB (version 7.01.0623 ou ultérieure), dans certaines circonstances, vous pouvez être confronté à une traduction des données de caractères de la page de code client vers la page de code du serveur, même si Autotranslation est désactivé pour la connexion.

Cause

Autotranslation n’est pas le seul mécanisme pouvant entraîner la conversion de la page de codes. 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 des versions ultérieures de l’un ou l’autre. Toutes les instructions SQL envoyées sous la forme d’un événement de langage sont converties en Unicode sur le client avant d’être envoyées au serveur. L’effet final est similaire à une Autotranslation de toutes les données transitant du client vers le serveur via un événement de langue, quel que soit le Autotranslation paramètre actuel de la connexion. Il ne présente pas de difficultés, sauf en cas de tentative de stockage de données de caractères non traduites à partir d’une page de codes autre que celle de SQL Server.

Solution de contournement

Ne stockez pas les données de la page de codes X dans une page de codes Y SQL Server (par exemple, les données de la page de code 950 dans une page de codes 1252 un serveur). Bien que cela était possible dans certaines circonstances avec les versions précédentes de SQL Server, il n’était jamais pris en charge. Sur un serveur SQL 1252, tout sauf un 1252 n’est pas un caractère valide. Les données de caractères non Unicode provenant d’une autre page de codes ne seront pas triées correctement et, dans le cas de données codées sur deux octets (DBCS), SQL Server ne reconnaîtra pas correctement les limites de caractères. Cela peut entraîner des problèmes importants.

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

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

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

Si votre situation exige que vous stockiez les données de la page de codes X dans une page de codes Y SQL Server, il existe deux façons de procéder de manière fiable :

  • Stockez les données dans des colonnes binaires ( BINARY/VARBINARY/IMAGE ).
  • Écrivez votre application pour utiliser des appels de procédure distante (RPC) pour toutes les instructions SQL qui traitent des données de caractères. Les données envoyées par le biais d’un événement RPC ne sont pas soumises à la conversion. Il n’existe aucun élément au niveau du pilote ou du DSN permettant de modifier le type des événements envoyés. L’envoi d’une commande en tant que langage ou événement 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 que la case à cocher effectuer la traduction des données de caractère dans les applications ODBC plus récentes) convertit les données de caractères de la page de code client en page de codes de serveur avant d’envoyer les données au serveur, en utilisant Unicode comme moyen 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 au format Unicode avant de les placer sur le câble, ce qui a un effet similaire à la traduction automatique, mais n’est pas régi par le paramètre de traduction automatique. En revanche, les données de caractères qui transitent du serveur vers les clients respectent l’indicateur de traduction automatique ; Si la conversion automatique est désactivée, les données arrivent dans l’application cliente avec les mêmes codes de caractères que les données avaient sur le serveur. De même, la conversion de données pour les événements RPC client à serveur peut être désactivée en désactivant la traduction automatique. Un script simple qui démontre comment le comportement affecte les événements de langage suit. Cet exemple a été exécuté à partir de l’analyseur de requêtes sur une page de code 1252 client se connectant à une page de codes 437 un serveur :

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

Les éléments suivants à l’exemple précédent :

  • Même si Autotranslation était désactivé pendant ce traitement par lots, le code de caractère 165 (yen dans la page de code 1252) a été converti en 157 (yen dans la page de code 437). Cela est dû au fait que le pilote ODBC a converti la chaîne SQL en Unicode avant de l’envoyer au serveur, afin que le serveur ait pu le convertir en caractère approprié pour le stockage dans la page de code 437.
  • Lorsque le client a exécuté une sélection pour extraire les données qui ont été stockées, le caractère 157 a été reçu non traduit au niveau du client (157 apparaît en tant que zone' 'sur un client de page de codes 1252). Cela est dû au fait que la conversion abordée dans cet article s’applique uniquement aux données envoyées du client vers le serveur, et non du serveur vers le client. Les données n’ont pas été traduites car le Autotranslation paramètre est désactivé.
-- 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, la réactivation Autotranslation n’a aucun effet sur la traduction du client vers le serveur (autrement dit, la même traduction correcte du code de caractère 165 vers le code de caractère 157 s’est produite), mais elle a eu un effet sur les données récupérées à partir du serveur. Lorsque l’instruction SELECT est exécutée cette fois (avec la Autotranslation méthode on), les symboles yen s’affichent correctement dans l’application de la page de code 1252, car ils ont été traduits du code de caractère 157 retour au code de caractère 165 par le Autotranslation mécanisme.

Vous verrez ce comportement (conversion d’événements de langue en Unicode sur le client) lors de l’utilisation d’un pilote ODBC SQL Server version 3,70 ou ultérieure et de la connexion à SQL Server 7,0 ou version ultérieure. Il ne se produit pas lors de l’utilisation d’anciens pilotes ODBC, ou lors de l’utilisation du pilote 3,7 pour se connecter à SQL Server 6,5 ou version antérieure. En outre, si vous stockez vos données dans des colonnes Unicode ( NCHAR/NVARCHAR/NTEXT ), la conversion ne sera pas un problème.

Pour plus d’informations sur la façon dont les données de caractère sont représentées dans SQL Server 2005, voir Character Data est représenté de manière incorrecte lorsque la page de code de l’ordinateur client diffère de la page de code de la base de données dans SQL Server 2005.