È possibile utilizzare percorsi relativi per i file dtsConfig dei pacchetti SSIS?

Question

Sto cercando di rendere i nostri pacchetti di SQL Server Integration Services il più portatili possibile e l'unica cosa che impedisce è che il percorso alla configurazione sia sempre un percorso assoluto, il che rende il test e la distribuzione un mal di testa. Ci sono suggerimenti per renderlo più gestibile?

Un altro problema è quando un altro sviluppatore ottiene il pacchetto fuori dal controllo del codice sorgente il percorso è specifico per la macchina degli sviluppatori.

Answer 1

Se si sta tentando di eseguire i pacchetti utilizzando Visual Studio, il percorso del file di configurazione verrà codificato. Quindi, se sposti il ??tuo progetto, dovrai cambiare il percorso nelle impostazioni del pacchetto. Per evitare ciò, è possibile utilizzare l'opzione Variabile d'ambiente per memorizzare il percorso del file di configurazione. Quindi dovrai solo cambiarlo.

Per i test e la distribuzione, tuttavia, è consigliabile utilizzare l'utilità dtexec per eseguire i pacchetti. Crea alcuni file batch per quello. Preferibilmente uno per ciascun ambiente diverso. Qui il percorso del file di configurazione può essere relativo.

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

Questo è se i tuoi pacchetti sono nel file system. Puoi anche memorizzarli in SQL Server. È inoltre possibile archiviare la configurazione in SQL Server che può fornire flessibilità.

Answer 2

Dopo diverse ore cercando di farlo funzionare ho trovato una soluzione qui (non il migliore, ma funziona)

1. Individua i file di configurazione (file dtsconfig) nella stessa directory del file della soluzione (file .sln)
2. SEMPRE aprire la soluzione facendo doppio clic sul file della soluzione (file .sln). Questo imposterà la "cartella di lavoro" dove si trova la soluzione, il tuo file di configurazione verrà letto correttamente

Altrimenti i percorsi relativi non hanno funzionato per me.

Answer 3

Scopri l'utilità gratuita che può modificare i percorsi dei file di configurazione SSIS senza BIDS: http://ssisconfigeditor.codeplex.com/

Answer 4

Il mio trucco standard per questi tipi di problemi è mappare le unità.

O usando un unità di rete mappata o utilizzando Subst (entrambi i metodi sono intercambiabili).

es. Mappare la posizione del pacchetto su N: \ quindi all'interno del pacchetto utilizzare i percorsi utilizzando N: \ MyParentPackage.dtsx, N: \ MyChildPackage.dtsx. I pacchetti possono trovarsi su unità totalmente diverse in cartelle diverse su macchine diverse, funzionerà una volta mappata la posizione del pacchetto su N: \

Di solito metto uno script a fianco dei file di progetto per mappare l'unità, che mappa l'unità in modo che possa essere facilmente eseguita prima. Un gotcha, se stai usando subst su VISTA - Win8, mappalo per elevato e non elevato.

Uso lo stesso approccio per i riferimenti ai file nei progetti di Visual Studio. Unico problema con questo approccio, che usi per risolvere troppi problemi nel tuo ambiente di sviluppo e finirai le lettere di unità.