Mettre à niveau des packages Integration Services
S’applique à : 
SQL Server SSIS Integration Runtime dans Azure Data Factory
Quand vous mettez à niveau une instance de SQL Server 2008 (10.0.x) vers la version actuelle de SQL Server, vos packages SQL Server 2008 Integration Services (SSIS) existants ne sont pas automatiquement mis à niveau vers le format de package utilisé par la version actuelle de SQL Server Integration Services. Vous devez choisir une méthode de mise à niveau et mettre à niveau vos packages manuellement.
Pour plus d’informations sur la mise à niveau des packages lorsque vous convertissez un projet en modèle de déploiement de projet, consultez Déployer des projets et des packages Integration Services Server (SSIS).
Choix d'une méthode de mise à niveau
Vous pouvez utiliser différentes méthodes pour mettre à niveau des packages SQL Server 2008 (10.0.x), SQL Server 2008 R2 (10.50.x), SQL Server 2012 (11.x) ou SQL Server 2014 (12.x). Pour certaines d'entre elles, la mise à niveau n'est que temporaire. Pour d'autres, elle est définitive. Le tableau suivant décrit chacune de ces méthodes et indique si la mise à niveau est temporaire ou définitive.
Notes
Quand vous exécutez un package SQL Server 2008 (10.0.x), SQL Server 2008 R2 (10.50.x), SQL Server 2012 (11.x) ou SQL Server 2014 (12.x) au moyen de l’utilitaire dtexec (dtexec.exe) qui est installé avec la version actuelle de SQL Server, la mise à niveau de package temporaire augmente la durée d’exécution. Le taux d'accroissement de temps d'exécution de package varie selon la taille du package. Pour éviter une augmentation pendant la durée d'exécution, il est recommandé d'effectuer la mise à niveau du package avant de l'exécuter.
Notes
Les composants Script qui référencent des assemblys liés à SSIS avec liaison à la version ne sont pas pris en compte par le processus de mise à niveau et restent inchangés. Une référence de mise à jour manuelle vers la nouvelle version est nécessaire.
| Méthode de mise à niveau | Type de mise à niveau |
|---|---|
| Recourez à l’utilitaire dtexec (dtexec.exe) qui installé avec la version actuelle de SQL Server pour exécuter un package SQL Server 2008 (10.0.x), SQL Server 2008 R2 (10.50.x), SQL Server 2012 (11.x) ou SQL Server 2014 (12.x). Pour plus d'informations, consultez Utilitaire dtexec. |
La mise à niveau de packages est temporaire. Les modifications ne peuvent pas être enregistrées. |
| Ouvrir un fichier de package SQL Server 2008 (10.0.x), SQL Server 2008 R2 (10.50.x), SQL Server 2012 (11.x) ou SQL Server 2014 (12.x) dans SQL Server Data Tools (SSDT). | La mise à niveau de packages est définitive si vous enregistrez le package, sinon, elle est temporaire. |
| Ajouter un package SQL Server 2008 (10.0.x), SQL Server 2008 R2 (10.50.x), SQL Server 2012 (11.x) ou SQL Server 2014 (12.x) à un projet existant dans SQL Server Data Tools (SSDT). | La mise à niveau de packages est permanente. |
| Ouvrez un fichier de projet SQL Server 2008 Integration Services (SSIS) ou ultérieur dans Visual Studio, puis utiliser l’Assistant Mise à niveau de packages SSIS pour mettre à niveau plusieurs packages dans le projet. Pour plus d’informations, consultez Mettre à niveau des packages Integration Services à l’aide de l’Assistant Mise à niveau de packages SSIS et Aide sur l’Assistant Mise à niveau de packages SSIS via la touche F1. |
La mise à niveau de packages est permanente. |
| Utilisez l’utilitaire Upgrade pour mettre à niveau un ou plusieurs packages Integration Services . | La mise à niveau de packages est permanente. |
Applications et composants personnalisés
SQL Server 2005 Integration Services (SSIS) ne fonctionne pas avec la version actuelle de SQL Server Integration Services.
Vous pouvez utiliser la version actuelle des outils SQL Server Integration Services pour exécuter et gérer des packages qui incluent des composants personnalisés SSIS SQL Server 2008 (10.0.x), SQL Server 2008 R2 (10.50.x), SQL Server 2012 (11.x) ou SQL Server 2014 (12.x). Nous avons ajouté quatre règles de redirection de liaison aux fichiers suivants pour faciliter la redirection des assemblys du runtime de la version 10.0.0.0 (SQL Server 2008 R2 (10.50.x)), version 11.0.0.0 ( SQL Server 2012 (11.x)) ou version 12.0.0.0 ( SQL Server 2014 (12.x)) vers la version 15.0.0.0 (SQL Server 2019 (15.x)).
DTExec.exe.config
dtshost.exe.config
DTSWizard.exe.config
DTUtil.exe.config
DTExecUI.exe.config
Pour utiliser SQL Server Data Tools afin de concevoir des packages incluant des composants personnalisés SQL Server 2008 (10.0.x), SQL Server 2008 R2 (10.50.x), SQL Server 2012 (11.x) ou SQL Server 2014 (12.x), vous devez modifier le fichier devenv.exe.config situé dans <lecteur>:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE.
Pour utiliser ces packages avec les applications clientes générées avec le runtime pour SQL Server 2019 (15.x), incluez les règles de redirection dans la section de configuration du fichier *.exe .config de l'exécutable. Les règles redirigent les assemblys du runtime vers la version 15.0.0.0 (SQL Server 2019 (15.x)). Pour plus d’informations sur la redirection des versions d’assemblys, consultez Élément <assemblyBinding> pour <runtime>.
Recherche d'assemblys
Dans SQL Server 2019 (15.x), les assemblys Integration Services ont été mis à niveau vers le .NET 4.0. Il existe un Global Assembly Cache distinct pour le .NET 4, situé dans <lecteur>:\Windows\Microsoft.NET\assembly. Vous trouverez tous les assemblys Integration Services sous ce chemin d'accès, en général dans le dossier GAC_MSIL.
Comme dans les versions antérieures de SQL Server, les principaux fichiers .dll d’extensibilité Integration Services se trouvent également dans <lecteur>:\Program Files\Microsoft SQL Server\130\SDK\Assemblies.
Présentation des résultats de mise à niveau de packages SQL Server
Au cours de la mise à niveau de packages, la plupart des composants et fonctionnalités des packages SQL Server 2008 (10.0.x), SQL Server 2008 R2 (10.50.x), SQL Server 2012 (11.x) ou SQL Server 2014 (12.x) sont convertis de façon fluide en leurs équivalents dans la version actuelle de SQL Server. Il existe toutefois certains composants et fonctionnalités pour lesquels aucune mise à niveau ne sera effectuée ou pour lesquels vous devez connaître les résultats. Le tableau suivant identifie ces composants et fonctionnalités.
Notes
Pour identifier les packages concernés par les points répertoriés dans le tableau, exécutez le Conseiller de mise à niveau.
| Composant ou fonctionnalité | Résultats de la mise à niveau |
|---|---|
| Chaînes de connexion | Pour les packages SQL Server 2008 (10.0.x), SQL Server 2008 R2 (10.50.x), SQL Server 2012 (11.x) ou SQL Server 2014 (12.x), les noms de certains fournisseurs ont changé et nécessitent des valeurs différentes dans les chaînes de connexion. Pour mettre à jour les chaînes de connexion, utilisez l'une des procédures suivantes : Utilisez l'Assistant Mise à niveau de packages SSIS pour mettre à niveau le package et sélectionnez l'option Mettre à jour les chaînes de connexion pour l'utilisation des nouveaux noms de fournisseurs . Dans SQL Server Data Tools (SSDT), sur la page Général de la boîte de dialogue Options, sélectionnez l'option Mettre à jour les chaînes de connexion pour l'utilisation des nouveaux noms de fournisseurs . Pour plus d’informations sur cette option, consultez la page Général. Dans SQL Server Data Tools (SSDT), ouvrez le package et modifiez manuellement le texte de la propriété ConnectionString. Remarque : vous ne pouvez pas appliquer les procédures ci-dessus pour mettre à jour une chaîne de connexion lorsque celle-ci est stockée dans un fichier de configuration ou dans un fichier de source de données, ou lorsqu’une expression définit la propriété ConnectionString . Pour mettre à jour la chaîne de connexion dans ces cas-là, vous devez mettre à jour le fichier ou l'expression manuellement. Pour plus d’informations sur les sources de données disponibles, consultez Sources de données. |
Scripts qui dépendent d'ADODB.dll
Les scripts de la tâche de script et du composant Script qui référencent explicitement ADODB.dll risquent de ne pas pouvoir être mis à niveau ou de ne pas pouvoir s'exécuter sur les ordinateurs qui ne disposent pas de SQL Server Management Studio ou de SQL Server Data Tools (SSDT) . Pour permettre la mise à niveau des scripts de la tâche de script et du composant Script, il est recommandé de supprimer la dépendance sur ADODB.dll. Ado.Net est l'alternative recommandée pour le code managé, à l'instar des scripts VB et C#.