Les données de caractères sont représentées de manière incorrecte lorsque la page de codes de l’ordinateur client diffère de celle de la base de données

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

Symptômes

Prenons l’exemple du scénario suivant :

• Vous utilisez SQL Server Management Studio pour interroger des données de caractères à partir d’une base de données SQL Server qui utilise un type de données non Unicode. Par exemple, la base de données SQL Server utilise le chartype de données , varcharou text .

• La page de codes de l’ordinateur client diffère de la page de codes de la base de données. La page de codes est associée au classement de la base de données.

Dans ce scénario, les données de caractères sont représentées de manière incorrecte.

Par exemple, vous pouvez rencontrer l’un des problèmes suivants :

• Les données de caractère sont représentées sous la forme d’un point d’interrogation (?). Vous pouvez rencontrer ce problème si vous insérez ou mettez à jour les données caractère en tant que type de données non Unicode avant d’interroger les données de caractère. Ce problème se produit si vous apportez cette modification à l’aide de SQL Server Management Studio sur un ordinateur client qui a une page de codes différente.

• Les données de caractères sont représentées en tant que données endommagées. Les données caractère de la page de codes X sont stockées dans une colonne non Unicode de la page de codes Y. En outre, les données de caractère ne sont pas traduites. Ce problème se produit lorsque vous interrogez les données de caractères à l’aide de SQL Server Management Studio.

  Remarque

  Lorsque vous interrogez les données caractère à l’aide de SQL Server Management Studio, les données de caractères sont représentées correctement si le paramètre Effectuer la traduction des données caractères (également appelé paramètreAuto Translate) est désactivé. Le Auto Translate paramètre est un paramètre de la propriété pour le ConnectionString fournisseur Microsoft OLE DB pour SQL Server et pour le fournisseur de données Microsoft .NET Framework pour OLE DB.

Cause

Ce problème se produit parce que les données caractère de la page de codes X sont stockées dans une colonne non Unicode de la page de codes Y, qui n’est pas prise en charge.

Dans SQL Server, lorsque vous utilisez un littéral de chaîne d’un type de données non Unicode, le littéral de chaîne est converti à l’aide de la page de codes par défaut de la base de données dérivée du classement de la base de données. Le stockage des données de caractères de la page de codes X dans une colonne de la page de codes Y peut entraîner une perte de données ou une altération des données.

Si les données caractère sont représentées en tant que données endommagées, les données ne peuvent être correctement représentées que si vous désactivez le paramètre pour le Auto Translate fournisseur Microsoft OLE DB pour SQL Server ou le fournisseur de données Microsoft .NET Framework pour OLE DB.

Solution de contournement

Pour contourner ce problème, utilisez l’une des méthodes suivantes :

Méthode 1 : Utiliser un type de données Unicode au lieu d’un type de données non Unicode

Remplacez les colonnes par un type de données Unicode pour éviter tous les problèmes causés par la traduction de pages de codes. Par exemple, utilisez le nchartype de données , nvarcharou ntext .

Méthode 2 : Utiliser un classement approprié pour la base de données

Si vous devez utiliser un type de données non-Unicode, assurez-vous toujours que la page de codes de la base de données et la page de codes des colonnes non Unicode peuvent stocker correctement les données non Unicode. Par exemple, si vous souhaitez stocker des données de caractères de page de codes 949 (coréen), utilisez un classement coréen pour la base de données. Par exemple, utilisez le Korean_Wansung_CI_AS classement pour la base de données.

Méthode 3 : utiliser le type de données « binary » ou « varbinary »

Si vous souhaitez que la base de données stocke et récupère directement les valeurs d’octet exactes des caractères gérés sans essayer d’effectuer la traduction de page de codes appropriée, utilisez le type de binary données ou varbinary .

Méthode 4 : Utiliser un autre outil pour stocker et récupérer des données et désactiver le paramètre « Traduction automatique »

Lorsque vous utilisez le fournisseur Microsoft OLE DB pour SQL Server pour vous connecter à une base de données qui a une page de codes différente et que vous essayez d’interroger des données caractères à partir d’une colonne de type de données non Unicode, veillez à stocker les caractères non traduits dans la base de données.

Pour contourner ce problème, procédez comme suit :

1. Convertissez manuellement les caractères en données brutes, puis insérez les données dans la base de données à l’aide de la page de codes de la base de données. Pour effectuer cette opération, utilisez un extrait de code similaire à celui-ci :

   string strsrc="가";string strsrc="가";
   string strtag=Encoding.GetEncoding(1252).GetString(Encoding.GetEncoding(949).GetBytes (strsrc));
   sql="insert into <tablename> (<column>,) values ('" + strtag + "')";
   // code for updating the database;
   

2. Lorsque vous souhaitez interroger les données, utilisez le fournisseur Microsoft OLE DB pour SQL Server ou le fournisseur de données Microsoft .NET Framework pour SQL Server pour vous connecter à la base de données, puis définissez le Auto Translate paramètre sur False. Pour effectuer cette opération, utilisez un extrait de code similaire à celui-ci :

   OleDbConnection conn=new OleDbConnection("Provider=SQLOLEDB;" +
   " Initial Catalog =<yourdatabase>;"+
   "User id=<youruserid>; Password=<yourpassword>;"+
   "Auto Translate=False");
   // code for representing the character data;
   

Plus d’informations

Pour reproduire le problème, procédez comme suit :

1. Sur l’ordinateur client qui a le coréen (CP949) comme page de codes par défaut, démarrez SQL Server Management Studio.

2. Connectez-vous à une base de données qui a l’anglais (CP1252) comme page de codes par défaut.

3. Créez une table dans la base de données à l’aide de la requête suivante :

   CREATE TABLE tbTest (A char(20), NA nchar(10), Comment char(20))
   

4. Insérez un caractère coréen dans la base de données à l’aide de la requête suivante :

   INSERT INTO tbTest (A,NA,Comment) VALUES('가',N'가','SQLServer/INSERT')
   

5. Créez une requête select pour récupérer les données à l’aide de la requête suivante :

   SELECT * FROM tbTest
   

Vous recevez les résultats suivants. La valeur de la colonne A est un point d’interrogation.

A                    NA         Comment
-------------------- ---------- --------------------
?                    가          SQLServer/INSERT

References

• 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 codes du client diffère de la page de codes du serveur

• Traduction automatique de SQL Native Client

• Traduction automatique du fournisseur SQL OLEDB