J'essaie d'importer des données d'une base de données d'un serveur vers une nouvelle table d'un serveur différent, à l'aide de l'Assistant d'importation et d'exportation de SQL Server. (SQL Server Management Studio 2012)
Dans l'assistant, j'ai coché la case "Rédiger une requête pour spécifier les données à transférer", et l'instruction SQL renvoie des données contenant les quatre colonnes suivantes:
+-----------------------------------------------------------------------------+
| ID(varchar(100)) | Title(text) | Description(text) | IsActive(tinyint)|
+-----------------------------------------------------------------------------+
Je veux changer les types pour la nouvelle table à
+----------------------------------------------------------------------------------------+
| ID(varchar(4)) | Title(varchar(200)) | Description(varchar(2000)) | IsActive(bit)|
+----------------------------------------------------------------------------------------+
Ainsi, dans la page "Mappages de colonnes" (Dans la page " Sélectionner les tables et vues sources ", j'ai cliqué sur " Modifier les mappages ..."), / j'ai changé le type de destination pour les types ci-dessus. Ensuite, après avoir cliqué sur "Suivant", dans la page "Vérification du mappage des types de données", un message d'erreur indiquant "Found 3 unknown column type conversion(s). You are only allowed to save the package
" s'affiche.
Le mappage de type de données affiche les informations suivantes:
icon Source Column Source Type Destination Column Destination Type Convert
----------------------------------------------------------------------------------
error ID 200 ID varchar
error Title 200 Title varchar
error Description 201 Description varchar
warning IsActive tinyint IsActive bit
Même si je ne change pas le type de données dans la page " Modifier les mappages ... ", j'obtiens la même erreur.
Je ne comprends pas ce que signifie "200" dans le contexte d'un type de données et comment puis-je importer ces données dans une nouvelle table d'un serveur différent?
J'apprécie toute aide.
Avec un peu d'expérimentation, cette erreur ne semble se produire que lorsque vous avez une requête en tant que source. La réponse acceptée ne fonctionnait pas pour moi car la copie dans un fichier plat entraînerait la même erreur.
Pour résoudre ce problème, j'ai mis ma requête dans une variable View
puis sélectionné Copy From one or more Tables Or Views
au lieu de Write a query...
.
Je suis ensuite passé par l'assistant normalement après cela et mes données sont passées sans erreur.
Malheureusement, c'est un bogue. Voir (et voter) les liens ci-dessous:
-> L'importation et l'exportation de SQL Server Wizard ne reconnaît pas Varchar et NVarchar
et
Une solution à long terme (à part Microsoft) (ou ont-ils déjà?) Se trouve également à quelques liens des réponses postées.
Sur la machine affectée, il existe un fichier XML qui définit un mappage code à valeur pour chaque type de transformation.
Ce qui est vu avec le "200" & "201" provoquant un échec, est un mappage manquant
.... eh bien, il n’aurait pas dû figurer comme "200/201", mais comme cela a été le cas, nous aurions aimé qu’il soit cartographié
Il peut être inséré manuellement si vous souhaitez jouer avec de telles configurations.
Voici la réponse que j'ai trouvée, assez loin en bas de page: http://social.msdn.Microsoft.com/Forums/sqlserver/en-US/97ff1f01-c02a-4c9a-b867-8eaecc464cfb/ Types-de-données-communes-2012-sp1-no-reconnues? Forum = sqlintegrationservices
Les fichiers de mappage sont dans C:\Program Files (x86)\Microsoft SQL Server\110\DTS\MappingFiles \
(ou équivalent)
Il en existe une pour chaque type de transformation source à destination.
Pour passer d’un serveur SQL à l’autre, examinez-les tels que
MSSQLToSSIS10.XML
MSSql9ToMSSql8.xml
MSSql10ToMSSql9.xml
Où tu vois
<!-- varchar -->
<dtm:DataTypeMapping >
<dtm:SourceDataType>
<dtm:DataTypeName>varchar</dtm:DataTypeName>
</dtm:SourceDataType>
<dtm:DestinationDataType>
<dtm:CharacterStringType>
<dtm:DataTypeName>DT_STR</dtm:DataTypeName>
<dtm:UseSourceLength/>
</dtm:CharacterStringType>
</dtm:DestinationDataType>
</dtm:DataTypeMapping>
Ajouter le mappage "200" pour correspondre à telle sorte que vous vous retrouvez avec
<!-- varchar -->
<dtm:DataTypeMapping >
<dtm:SourceDataType>
<dtm:DataTypeName>varchar</dtm:DataTypeName>
</dtm:SourceDataType>
<dtm:DestinationDataType>
<dtm:CharacterStringType>
<dtm:DataTypeName>DT_STR</dtm:DataTypeName>
<dtm:UseSourceLength/>
</dtm:CharacterStringType>
</dtm:DestinationDataType>
</dtm:DataTypeMapping>
<dtm:DataTypeMapping >
<dtm:SourceDataType>
<dtm:DataTypeName>200</dtm:DataTypeName>
</dtm:SourceDataType>
<dtm:DestinationDataType>
<dtm:CharacterStringType>
<dtm:DataTypeName>DT_STR</dtm:DataTypeName>
<dtm:UseSourceLength/>
</dtm:CharacterStringType>
</dtm:DestinationDataType>
</dtm:DataTypeMapping>
Fixez nvarchar et tous les autres de la même manière!
Je parie que les colonnes de texte ne peuvent pas être insérées dans des colonnes varchar avec l'Assistant. En fonction de la taille de la table, vous pouvez exporter la source au format csv via SSMS, puis l’importer. Cela devrait fonctionner, mais si vous avez plusieurs tables à importer, vous pouvez ajouter un serveur lié. Ensuite, vous pouvez simplement qualifier l'ancienne table ou la nouvelle table de la manière suivante:
insert into [new_server].database.dbo.tablename
select * from old_table
Je sais que SQL2000 est une tâche ardue pour la création de serveurs liés, bien que je suppose que vous essayez d'exporter depuis que vous avez des colonnes de texte.
J'ai pu contourner ce problème en transformant les champs de caractères sous la forme char (##) dans le code SQL, puis en modifiant les types de données de destination en varchar (##). Les champs peuvent avoir besoin d'être rognés avant d'être utilisés, mais l'importation fonctionne.
Ceci est le bug et vient d'être corrigé dans SQL SERVER 2012 SP2 .
Vous n'avez vraiment pas besoin de jouer avec la configuration, les vues ou quoi que ce soit d'autre. Sauvegardez simplement le package SSIS et exécutez-le en double-cliquant dessus dans l'explorateur. Ceci lancera l'utilitaire "Execute Package" (DTExecUI.exe dans le dossier ManagementStudio) qui devrait exécuter le package sans erreur.
La solution la plus rapide consiste à exporter les données vers une nouvelle table de la même base de données (source) à l'aide de l'assistant d'importation/exportation. Exportez ensuite les données de la nouvelle table . D'une manière ou d'une autre, l'assistant d'importation/exportation fonctionne de manière magique (pas vraiment) au moment où il crée la nouvelle table . Merci Jyoti d'avoir mis fin à la peine d'utiliser l'importation./assistant d’exportation.