Erreurs dans SQL Server lors de l'importation d'un fichier CSV malgré l'utilisation de varchar (MAX) pour chaque colonne
J'essaie d'insérer un gros fichier CSV (plusieurs concerts) dans SQL Server, mais une fois que j'ai effectué l'importation Wizard) et que j'essaie enfin d'importer le fichier, j'obtiens le rapport d'erreur suivant:
Exécution des messages (d'erreur) Erreur 0xc02020a1: flux de données Tâche 1: la conversion de données a échoué. La conversion des données de la colonne "" Titre "" a renvoyé la valeur d'état 4 et le texte d'état "Le texte a été tronqué ou un ou plusieurs caractères ne correspondaient pas dans la page de code cible.". (Assistant d'importation et d'exportation SQL Server)
Erreur 0xc020902a: Tâche de flux de données 1: La "Source - Train_csv.Outputs [Sortie de fichier plat]. Colonnes [" Titre "]" a échoué car une troncature s'est produite et la disposition de ligne de troncature sur "Source - Train_csv.Outputs [Source de fichier plat Sortie] .Columns ["Title"] "spécifie un échec lors de la troncature. Une erreur de troncature s'est produite sur l'objet spécifié du composant spécifié. (Assistant d'importation et d'exportation SQL Server)
Erreur 0xc0202092: Tâche de flux de données 1: une erreur s'est produite lors du traitement du fichier "C:\Train.csv" sur la ligne de données 2. (Assistant d'importation et d'exportation SQL Server)
Erreur 0xc0047038: Tâche de flux de données 1: Code d'erreur SSIS DTS_E_PRIMEOUTPUTFAILED. La méthode PrimeOutput sur Source - Train_csv a renvoyé le code d'erreur 0xC0202092. Le composant a renvoyé un code d'échec lorsque le moteur de pipeline a appelé PrimeOutput (). La signification du code d'échec est définie par le composant, mais l'erreur est fatale et le pipeline a cessé de s'exécuter. Il peut y avoir des messages d'erreur postés auparavant avec plus d'informations sur l'échec. (Assistant d'importation et d'exportation SQL Server)
J'ai créé le tableau dans lequel insérer le fichier en premier, et j'ai défini chaque colonne comme contenant varchar (MAX). Je ne comprends donc pas comment ce problème de troncature peut toujours se produire. Qu'est-ce que je fais mal?
Dans SQL Server Import and Export Wizard, vous pouvez ajuster les types de données source dans l’onglet Advanced (ceux-ci deviennent les types de données de la sortie si vous créez une nouvelle table. juste utilisé pour le traitement des données source).
Les types de données sont très différents de ceux de MS SQL, au lieu de VARCHAR(255), il s'agit de DT_STR Et la largeur de la colonne de sortie peut être définie sur 255. Pour VARCHAR(MAX) c'est DT_TEXT.
Ainsi, dans la sélection de la source de données, dans l'onglet Advanced, modifiez le type de données de toutes les colonnes incriminées de DT_STR À DT_TEXT (Vous pouvez sélectionner plusieurs colonnes et les modifier toutes immediatement).
Cette réponse peut ne pas s'appliquer universellement, mais elle a corrigé l'occurrence de l'erreur que je rencontrais lors de l'importation d'un petit fichier texte. Le fournisseur de fichier à plat importait en fonction de colonnes de texte fixes de 50 caractères dans la source, ce qui était incorrect. Aucune quantité de remappage des colonnes de destination n'a affecté le problème.
Pour résoudre le problème, dans la section "Choisissez une source de données" du fournisseur de fichiers à plat, après avoir sélectionné le fichier, un bouton "Suggérer les types .." apparaît sous la liste des colonnes de saisie. Après avoir appuyé sur ce bouton, même si aucune modification n'a été apportée à la boîte de dialogue, le fournisseur de fichier à plat a ensuite interrogé le fichier .csv source, puis correctement a déterminé la longueur des champs du fichier source.
Une fois cette opération effectuée, l'importation s'est poursuivie sans autre problème.
L’éditeur avancé n’a pas résolu mon problème, mais j’ai été contraint de modifier le fichier dtsx via le bloc-notes (ou votre éditeur de texte/xml préféré) et de remplacer manuellement les valeurs dans les attributs.
length="0"dataType="nText" (J'utilise unicode)
Faites toujours une sauvegarde du fichier dtsx avant d’éditer en mode texte/xml.
Exécution de SQL Server 2008 R2
Je pense que c'est un bogue, appliquez la solution de contournement, puis réessayez: http://support.Microsoft.com/kb/281517 .
Rendez-vous également dans l'onglet Avancé et confirmez si la longueur des colonnes cibles est Varchar (max).
Allez dans l'onglet Avancé ----> type de données de la colonne ---> Ici, changez le type de données de DT_STR à DT_TEXT et la largeur de colonne 255. Vous pouvez maintenant vérifier qu'il fonctionnera parfaitement.
Problème: le fournisseur de base de données Jet OLE) lit une clé de registre pour déterminer le nombre de lignes à lire pour deviner le type de la colonne source. Par défaut, la valeur de cette clé est 8. Par conséquent, , le fournisseur analyse les 8 premières lignes des données source afin de déterminer les types de données pour les colonnes. Si un champ ressemble à du texte et que la longueur des données est supérieure à 255 caractères, la colonne est saisie en tant que champ mémo. aucune donnée d’une longueur supérieure à 255 caractères dans les 8 premières lignes de la source, Jet ne peut pas déterminer avec précision la nature du type de données, car la longueur des 8 premières lignes de la feuille exportée est inférieure à 255 source comme VARCHAR (255) et incapable de lire les données de la colonne ayant la plus grande longueur.
Correction: la solution consiste simplement à trier la colonne de commentaires par ordre décroissant. À partir de 2012, nous pouvons mettre à jour les valeurs dans l'onglet Avancé de l'assistant d'importation.