Discussion :

[matman]

Bonjour,
Je travaille sur une transformation SSIS dans un dossier. Ce dossier est amené à être déplacé sur plusieurs machines différentes. Or le problème est que j'utilise 4 packages et que pour créer les connexions à ces packages, j'entre un chemin qui ne peut être qu'absolu et la transformation ne donc fonctionnera que si les package sont toujours placées au même endroit, ce qui n'est pas garanti étant donné les problèmes de droits qui peuvent exister.
J'ai donc essayé de créer un script qui détecterait l'emplacement physique du .dtsx appelé ce qui me permettrait de modifier mes connexion avec le chemin courant. Seulement je n'arrive pas à savoir comment accéder à la propriété emplacement du package courant.

[FrancoisJehl]

Je me suis déjà cassé les dents dessus sans succès: essaie de voir si tu ne peux pas plutôt la passer en externe, i.e. lancer les packages via un Batch qui prend la valeur du PATH courant et la pose dans une variable, transmise au package via DTEXEC.

François JEHL
Consultant Formateur
MCITP/MCT Business Intelligence Development
Winwise (Paris)
http://fjehl.blogspot.com

[brunoSCP]

Bonjour,
Je relance cette discussion en 2010 pour voir si de nouvelles idées ont germées dans l'esprit de certain.

La demande de Matma correspond pilepoil à mon problème et je n'y ajouterai rien.

La solution batch de François ne me conviens pas, peut-être a t-il persévéré vers autre chose.

[FrancoisJehl]

Malheureusement rien de vraiment neuf: j'en suis arrivé à la conclusion qu'il me semble impossible que le package connaisse son emplacement de lancement... Ce qui peut faire sens. Pas mal de mes contacts abondent dans ce sens là.

[brunoSCP]

Merci de ta réponse.
Je pense que le fait pour un package de connaitre son emplacement a au contraire une grande importance.
Mais c'est peut-être dû à la manière dont nous travaillons qui n'est peut-être pas orthodoxe.
Nos packages complexes sont en général décomposés en plusieurs packages simples qui sont exécutés à partir d'un package appelé Lanceur. C'est bien sûr dans ce ce lanceur que se pose le problème des connexions aux .dtx avec une ConnectionString en dur.

Nos développeurs voudraient récupérer la solution visual studio à partir de Source Safe, faire leur modifs et tester en local sans déployer unitairement les packages sur un serveur de test.

On a trouvé une parade un peu bidon qui consiste à fixer la connectionString à partir d'une expression qui utilise une variable user:VisualStudioProjectPath que nous initialisons par une tache de script en début du lanceur. Ce script récupère dans la base de registre la clé qui donne le répertoire par défaut des projet visual studio et le concatène au nom du projet.

C'est pas top mais ça marche et ça nous permet de continuer à travailler de manière impropre mais commode .

[Jinroh77]

Je ne sais pas si la situation correspond exactement, mais souvent, nous utilisons sur les serveurs et les postes développeurs un répertoire partagée, pointant sur le poste lui-même.

Ex :
Chacun des développeur, fait pointer son TFS, Sourcesafe etc où il veut.
Il crée alors un partage local sur ce répertoire.
Il crée connecte ensuite un lecteur réseau qu'il appelle d'une lettre précise sur ce répertoire.
Chacun des dév a alors un disque I (par exemple) qui pointe tous vers la même architecture de dossier etc...

Faire de même sur le serveur où son exécuter les packages et c'est réglé.

Attention, en fonction du type de déclenchement des packages, il faudra sûrement créer un véritable disque I (physique) sur ce serveur.

Les dév ne doivent pas oublier de faire pointer leurs chaines de connections fichiers vers le I et non leur répertoire local

[brunoSCP]

Merci,
Je soumet ta proposition à la prochaine réunion méthodo.
Je mettrai sur ce fil le résultat de nos empoignades

[FrancoisJehl]

Bah le truc le plus approchant de ce que vous cherchez à faire c'est la bidouille de Galloway pour faire de l'adressage de config en relatif... mais au final il récupère le working directory du process qui a lancé le package, ce qui doit sans problèmes se choper en script... http://www.artisconsulting.com/blogs...b857634f&ID=15