(ou “Le post de l’After Gameworks Party”)

Un post qui est bloqué dans ma stack depuis quelques semaines déjà.

Le sujet est simple, il traite de l’ordre de prise en compte de la configuration d’un package SSIS.

Si vous voulez configurer une variable dynamiquement sur votre environnement d’exécution, plusieurs choix s’offrent à vous :

• le mettre en dur dans votre package avant déploiement (beurk)
• utiliser un fichier de configuration (.dtsconfig)
• utiliser une configuration qui vient d’une base de données
• utiliser une directive /SET à l’exécution (disponible dans SQL Agent et en ligne de commande)

Note : Personnellement, j’utilise principalement le dernier choix.

Le problème vient de l’utilisation d’un DTSconfig. Prenons un exemple :

• dans votre package vous référencez un fichier de configuration qui se trouve dans c:\config-dev.dtsconfig
• en passant en production, vous indiquez dans le SQL Agent votre configuration de production c:\config-prod.dtsconfig
• en production vous avez quand même un fichier config-dev.dtsconfig à la racine de C:
• A l’exécution, c’est le fichier de configuration de DEV qui est pris en compte !

Mais pourquoi ? Regardons un peu la documentation :

Using the /ConfigFile option to load run-time configurations for the same property values that are also set by design-time configurations : Has no effect. The new values are overwritten when the utility reloads the design-time configurations after it applies the run-time options.

Ce paragraphe est tiré d’une page appelée Behavior Changes to Integration Services Features in SQL Server 2008 R2.

En fait, depuis 2008 R2, dtexec recharge le fichier se trouvant dans le chemin initial (celui utilisé pendant le développement dans BIDS) après avoir chargé tous ceux qu’on lui donne explicitement.

Oui, c’est absurde mais c’est By Design.

Evidemment, si le fichier config-dev.dtsconfig ne se trouve pas en production, aucun problème mais si vous travaillez avec la même arborescence (lecteur compris) ou si vous travaillez avec des UNC, soyez très vigilants.

Ni moi ni aucun de mes clients n’ont rencontré de soucis mais Christophe y a été confronté chez un de ses clients.

Annexe :

Dans SQL Server 2012, si vous migrez vos package sous le nouveau mode d’exécution, il n’y a plus de DTSConfig, donc plus de souci.

Oui, j’ai bien dit qu’en 2012 il n’y a plus de DTSConfig. Venez voir ma session sur SSIS 2012 aux Journées SQL Server pour en savoir plus.

Pour l’anecdote, ce poste vient d’une discussion très tard après une soirée du SQL PASS Summit dans la chambre d’hôtel que je partageai avec Christophe. Cette discussion s’est vite transformée en débat animé mais se termine sur la conclusion suivante : ce n’est pas un bug puisque c’est documenté, c’est donc une feature…by design

PS : tu vois Christophe que j’ai blogué sur le sujet.