Est-il possible d'utiliser des chemins relatifs pour les fichiers dtsConfig de packages SSIS?

Question

J'essaie de rendre nos paquets SQL Server Integration Services aussi portables que possible et la seule chose qui empêche que le chemin de la config soit toujours un chemin absolu, ce qui rend le test et le déploiement un vrai casse-tête. Y a-t-il des suggestions pour rendre cela plus maniable?

Un autre problème est lorsqu'un autre développeur obtient le paquet hors du contrôle de la source, le chemin est spécifique à la machine du développeur.

Answer 1

Si vous essayez d'exécuter vos packages à l'aide de Visual Studio, le chemin du fichier de configuration sera codé en dur. Donc, si vous déplacez votre projet, vous devrez changer le chemin dans les paramètres du paquet. Pour éviter cela, vous pouvez utiliser l'option Variable d'environnement pour stocker le chemin du fichier de configuration. Ensuite, vous aurez seulement besoin de changer cela. Cependant, pour les tests et le déploiement, vous devriez probablement utiliser l'utilitaire dtexec pour exécuter vos paquets. Faites quelques fichiers batch pour cela. De préférence un pour chaque environnement différent. Ici, le chemin du fichier de configuration peut être relatif.

dtexec /File Package.dtsx /Conf configuration.dtsConfig" 

Ceci est le cas si vous avez des paquets dans le système de fichiers. Vous pouvez également les stocker dans SQL Server. Vous pouvez également stocker votre configuration dans SQL Server, ce qui peut offrir une certaine flexibilité.

Answer 2

Après plusieurs heures à essayer de faire ce travail que je trouve une solution here (pas le meilleur, mais il fonctionne)

1. Localisez vos fichiers de configuration (fichiers dtsconfig) dans le même répertoire que votre fichier de solution (fichier .sln)
2. TOUJOURS ouvrir votre solution en double-cliquant sur le fichier de solution (fichier .sln). Cela configurera le «dossier de travail» où la solution sera installée, votre fichier de configuration sera lu correctement.

Sinon, les chemins relatifs n'ont pas fonctionné pour moi.

Answer 3

Découvrez l'utilitaire gratuit qui peut modifier les chemins de fichier de configuration SSIS sans BIDS: http://ssisconfigeditor.codeplex.com/

Answer 4

Mon stock truc standard pour ce genre de problèmes cartographient les lecteurs.

Soit en utilisant un mapped network drive soit en utilisant Subst (les deux méthodes sont interchangeables).

par exemple. Mappez l'emplacement de votre paquet sur N: \ puis à l'intérieur de votre paquet, utilisez les chemins en utilisant N: \ MyParentPackage.dtsx, N: \ MyChildPackage.dtsx. N: \

Je place généralement un script le long des fichiers de projet pour mapper le lecteur, qui peut être sur des lecteurs totalement différents dans différents dossiers sur différentes machines, cela fonctionnera une fois que vous mappez l'emplacement du paquet. mappe le lecteur afin qu'il puisse être facilement exécuté avant. Un gotcha, si vous utilisez subst sur VISTA - Win8, mappez-le pour élevé et non élevé. J'utilise la même approche pour les références de fichiers dans les projets Visual Studio. Seul problème avec cette approche, vous utilisez pour résoudre trop de problèmes dans votre environnement de développement et vous n'aurez plus de lettres de lecteurs.