J'ai récemment rencontré une erreur en travaillant avec bcp. Voici l'erreur.
SQLState = 22001, NativeError = 0 Erreur = [Microsoft] [SQL Server Native Client 10.0] Données de chaîne, troncation à droite
J'essaie de décompresser les données dans une table intermédiaire qui ne comporte aucune contrainte et dont les types de données sont également assez volumineux par rapport aux données. J'ai environ 11 fichiers de différentes tables en cours de bcp'd et compressés dont un seul fichier lors de la décompression des erreurs. C'est la commande que j'utilise avec succès. Très récemment (en essayant de faire une copie du WH et de mettre en place le processus), j'ai eu des problèmes.
bcp.exe employee_details dans employee_details.dat -n -E -S "nom_serveur" -U sa -P "mot de passe"
J'ai essayé de changer les commandes en -C -T -S qui fonctionnait lorsque j'ai donné le format manuellement. C'est un paquet très gros et important que je dois charger dans mon WH.
Je ne sais pas si je vois un fichier de format ici ou pas. Toute aide est nécessaire.
Merci
Fille à la cannelle.
Nous avons également rencontré le même problème lors de la mise en œuvre du PCA. Il s’est avéré qu’il s’agissait d’un nouveau caractère de ligne dans le fichier .dat.
Affichez le fichier dans Notepad ++ et cliquez sur "Afficher tous les caractères" pour afficher le nouveau caractère de ligne.
BCP lève l’erreur suivante avec l’option -r "\ r\n", c’est-à-dire avec la commande ci-dessous
bcp dbo.Test in C:\Test.dat -c -t "|" -r "\r\n" -S "DBServerName" -T -E
"SQLState = 22001, NativeError = 0 Erreur = [Microsoft] [SQL Server Native Client 10.0] Données de chaîne, troncation à droite"
BCP traite toutes les lignes du fichier comme une seule ligne avec l'option -r "\ n" ou -r "\ r", c'est-à-dire avec la commande ci-dessous.
bcp dbo.Test in C:\Test.dat -c -t "|" -r "\n" -S "DBServerName" -T -E
Le problème a été résolu lorsque nous avons utilisé la valeur Haxadecimale (0x0a) pour le caractère de nouvelle ligne dans la commande BCP
bcp dbo.Test in C:\Test.dat -c -t "|" -r "0x0a" -S "DBServerName" -T -E
Pour nous, il s'est avéré que le fichier que nous essayions de télécharger était au format Unicode au lieu du format ANSI.
Il existe un commutateur -N, mais nos tables ne contenaient aucune donnée NVARCHAR.
Nous venons de sauvegarder le fichier au format ANSI et cela a fonctionné, mais si vous avez des données NVARCHAR ou si vous devez utiliser le commutateur -N
Voir TechNet - Utilisation du format natif Unicode pour importer ou exporter des données
une erreur de troncature à droite bcp se produit lorsqu'il y a trop de données qui peuvent être insérées dans une seule colonne. (Windows a CRLF ou '\ r\n' et UNIX a '\ n') peut également provoquer cette erreur. Exemple Votre fichier de format contient Windows CRLF, c.-à-d. '\ R\n' comme terminateur de ligne, mais le fichier contient '\ n' comme fin de ligne. Cela voudrait dire qu'il faudrait insérer tout le fichier sur 1 ligne (plutôt 1 colonne), ce qui entraînerait une erreur de troncature à droite.
Je recevais aussi le message de troncature. Après des heures passées à chercher des forums et à essayer des solutions, je me suis enfin mis au travail.
La raison du message de troncature était parce que j'étais suffisamment crédule pour penser que le fait de placer le nom de la colonne dans le fichier de format importait réellement. C'est le chiffre précédent qui semble dicter l'endroit où les données sont chargées.
Mon fichier d'entrée ne contenait pas de données pour la troisième colonne du tableau. Donc, voici à quoi ressemblait mon fichier de format.
... "," 1 Cust_Name SQL_Latin1...
... "," 2 Cust_Ref SQL_Latin1...
... "," 3 Cust_Amount SQL_Latin1...
... "\r\n" 4 Cust_notes SQL_Latin1...
Mon fichier d'entrée ressemblait à ceci:
Jones,ABC123,200.67,New phone
Smith,XYZ564,10.23,New SIM
La table ressemblait
Cust_Name Varchar(20)
Cust_Ref Varchar(10)
Cust_Type Varchar(3)
Cust_amount Decimal(10,2)
Cust_Notes Varchar (50)
Cust_Tel Varchar(15)
Cust......
J'avais supposé en donnant le nom de la colonne dans le fichier de format que les données iraient dans la colonne appropriée de la table.
Cela fonctionne cependant car le numéro de colonne est important et le nom de colonne est noise.
... "," 1 A SQL_Latin1...
... "," 2 B SQL_Latin1...
... "," 4 C SQL_Latin1...
... "\r\n" 5 D SQL_Latin1...
Ouvrez les fichiers dans le bloc-notes ++. Allez à l'onglet Affichage-> Afficher les symboles-> Afficher tous les caractères. Je faisais également face au même problème dans l’onglet .tsv files.one était mal placé.
Je sais que cela est vieux - mais je viens de rencontrer un cas où j'ai eu cette erreur, il s'avère qu'un de mes champs numériques avait plus de décimales autorisées par le schéma.
En retard, mais quand même: dans mon cas, j'ai exactement celui-ci
SQLState = 22001, NativeError = 0
Error = [Microsoft][ODBC Driver 11 for SQL Server]String data, right truncation
Et le problème était que le schéma a changé . La base de données cible avait deux nouveaux champs. Une fois que j'ai installé le schéma précédent, l'importation a réussi.