Migration des packages DTS

Mis à jour : 17 juillet 2006

SQL Server 2005 Integration Services (SSIS) fournit plusieurs options pour conserver les solutions créées avec les outils DTS et un modèle d'objet SQL Server 2000. Vous pouvez migrer des packages DTS au format SQL Server 2005, continuer à exécuter des packages DTS en utilisant le runtime DTS SQL Server 2000 ou intégrer des packages DTS aux solutions SQL Server 2005 Integration Services en utilisant la tâche d'exécution de package DTS 2000.

Lorsque vous migrez des packages DTS SQL Server 2000 au format SQL Server 2005 Integration Services, la structure du package migré et le degré d'aboutissement de la migration dépendent du contenu du package de départ.

Remarque :
L'Assistant Migration de package conserve les packages DTS intacts et inchangés.

Les résultats de la migration d'un package peuvent être les suivants :

• Les packages peuvent être migrés avec succès et migrés entièrement car ils ne contiennent que des tâches et n'utilisent que des fonctionnalités qui correspondent aux tâches et aux fonctionnalités SQL Server 2005 Integration Services (SSIS).
• Les packages contiennent des tâches et des fonctionnalités DTS SQL Server 2000 qui ne peuvent pas être migrées directement vers des tâches et des fonctionnalités SQL Server 2005 Integration Services (SSIS), mais la fonctionnalité du package est préservée grâce à l'utilisation de packages SQL Server 2000 encapsulés.

Remarque :
Dans certains cas, comme lorsque le nom du package contient des caractères non valides (/ \ : [ ] . =), ou lorsque le package contient des objets non enregistrés, l'Assistant Migration de package ne peut pas effectuer la migration avant la résolution de ces problèmes.

Si toutes les tâches du package peuvent être mappées à de nouvelles tâches dans SQL Server 2005, la structure du package migré est très proche de la structure du package SQL Server 2000. Inversement, si les tâches ne correspondent pas directement aux tâches SQL Server 2005, la migration modifie la structure du package. Chaque tâche non migrée conserve son format SQL Server 2000 et est encapsulée dans une tâche d'exécution DTS 2000. Les tâches personnalisées dans les packages sont également migrées de cette façon. Pour plus d'informations, consultez Migration de tâches.

D'autres éléments de package tels que les contraintes de précédence, les connexions et les variables sont migrées vers l'élément équivalent dans SQL Server 2005. Pour plus d'informations, consultez Migration des contraintes de précédence, Migration des connexions et Migration de variables.

Les mots de passe de package ne sont pas migrés avec les packages migrés en tant que packages SQL Server 2005 Integration Services (SSIS). Toutefois, SQL Server 2005 prend en charge les mots de passe de package dans les packages SQL Server 2000 et dans la tâche d'exécution de package DTS 2000. Une tâche d'exécution de package DTS 2000 dans un package SQL Server 2005 peut passer le mot de passe du package à un package SQL Server 2000. Pour plus d'informations, consultez Migration des mots de passe.

La tâche de script ActiveX dans SQL Server 2005 est souvent capable d'exécuter le code de script qui est migré à partir des scripts ActiveX dans des packages DTS SQL Server 2000 sans modification supplémentaire. Toutefois, les références aux objets de package DTS SQL Server 2000 ne sont pas prises en charge. Pour plus d'informations, consultez Migration de scripts.

Les annotations de texte entrées dans le Concepteur DTS, ainsi que les paramètres de journalisation de package et de gestion des erreurs, ne sont pas migrés.

Une fois les packages migrés, ils doivent être ouverts pour vérifier la présence éventuelle de problèmes et notamment les échecs de validation. Par exemple, certains packages dépendent de tâches précédentes dans le même package pour créer ou préparer les sources de données ou les destinations de données et, si ces objets sont introuvables, la validation peut échouer. Pour résoudre un problème de validation de ce type, affectez à la propriété DelayValidation la valeur true dans la tâche ou dans un autre objet conteneur, ou bien affectez à la propriété ValidateExternalMetadata la valeur false dans le composant de flux de données concerné.

Remarque :

Après avoir migré des packages à partir de Management Studio, connectez-vous à l'instance locale de Integration Services dans l'Explorateur d'objets pour observer les packages migrés. Si vous avez sélectionné SQL Server comme destination, les packages migrés sont visibles sous le nœud MSDB. Si vous avez sélectionné un dossier de système de fichiers comme destination, cliquez avec le bouton droit sur le nœud Système de fichiers, puis sélectionnez Importer un package pour afficher les packages migrés. Une fois que vous avez effectué la migration des packages à partir de BI Development Studio, les packages migrés sont enregistrés dans le dossier de système de fichiers que vous avez spécifié, puis ajoutés au projet ouvert sous le nœud Packages SSIS. Il est impossible d'ouvrir ou de modifier les packages DTS dans BI Development Studio.

Dans cette section

Historique des modifications

Voir aussi

Concepts

Compatibilité descendante de SQL Server 2005 Integration Services

Autres ressources

SQL Server Integration Services

Aide et Informations

Assistance sur SQL Server 2005