Que signifie l'erreur SQL Server "String Data, Right Truncation" et comment puis-je la corriger?
Nous effectuons des tests de performances sur notre site Web et nous obtenons souvent l'erreur suivante:
*** 'C:\inetpub\foo.plex' log message at: 2008/10/07 13:19:58
DBD::ODBC::st execute failed: [Microsoft][SQL Native Client]String data, right truncation (SQL-22001) at C:\inetpub\foo.plex line 25.
La ligne 25 est la suivante:
SELECT DISTINCT top 20 Zip_CODE, CITY, STATE FROM Zipcodes WHERE (Zip_CODE like ?) OR (CITY like ?) ORDER BY Zip_CODE
Et enfin, c'est le code Perl.
Des idées?
EDIT : le problème ici était que je cherchais dans le fichier Zip avec la chaîne "74523%" qui est trop longue. J'ai fini par ne pas ajouter le% s'ils donnent cinq chiffres.
Soit le paramètre fourni pour Zip_CODE est plus grand (en longueur) que Zip_CODEs largeur de colonne ou le paramètre fourni pour CITY est plus grand (en longueur) que CITYs largeur de colonne.
Il serait intéressant de connaître les valeurs fournies pour les deux ? espaces réservés.
J'ai contourné le problème en utilisant une conversion sur le "?", Donc mon code ressemble à convert (char (50) ,?) et cela s'est débarrassé de l'erreur de troncature.
Il s'agit d'un problème connu du pilote mssql ODBC. Selon le blog de Microsoft:
Le paramètre ColumnSize de SQLBindParameter fait référence au nombre de caractères dans le type SQL, tandis que BufferLength est le nombre d'octets dans le tampon de l'application. Cependant, si le type de données SQL est varchar (n) ou char (n), l'application lie le paramètre en tant que SQL_C_CHAR ou SQL_C_VARCHAR, et le codage de caractères du client est UTF-8, vous pouvez obtenir une "données de chaîne, troncature droite" "erreur du pilote même si la valeur de ColumnSize est alignée avec la taille du type de données sur le serveur. Cette erreur se produit car les conversions entre les codages de caractères peuvent modifier la longueur des données. Par exemple, un caractère d'apostrophe droite (U + 2019) est codé dans CP-1252 comme le seul octet 0x92, mais dans UTF-8 comme la séquence de 3 octets 0xe2 0x80 0x99.
Vous pouvez trouver l'article complet ici .