Configurations de package SSIS 2008 ignorées

10

Avec la modification des configurations de package en 2008 par rapport à 2005 lorsque je spécifie / ConfigFile something.dtsConfig sur la ligne de commande, les variables définies dans le package conservent leurs valeurs au moment de la conception au lieu d'utiliser les paramètres du fichier de configuration.

Je ne suis pas sûr de comprendre comment utiliser le fichier de configuration externe. J'ai lu des articles qui disent que seules les configurations définies au moment du design écraseront la charge du fichier externe. Est-ce à dire que je peux changer les variables en chaînes vides et qu'elles seront écrasées? Je ne peux pas supprimer complètement la variable! Et les entiers?

J'ai vu des articles qui mentionnent la désactivation de l'utilisation des configurations de package dans le package.

Je peux utiliser l'éditeur de package SSIS ou un éditeur XML pour modifier le chemin du fichier de configuration dans le package, puis il utilisera les paramètres de ce fichier "en dernier" (quelle que soit l'option externe / ConfigFile), mais je ne veux pas être changer le paquet. Je veux un package avec Test.dtsConfig et Production.dtsConfig et pouvoir échanger d'avant en arrière sans changer le package.

Quelle est la méthode recommandée pour le faire maintenant?

Cade Roux
la source
1
Vous pourriez trouver votre soulagement ici , sur le forum SQLServerCentral. Une explication du changement de comportement est ici - section Changements de comportement liés aux configurations de package.
Marian
Veuillez consulter les fichiers suivants pour avoir une idée des packages et des configurations dont je parle: configuration et lots , package de test et fichier Lisez - moi .
Marian

Réponses:

10

Vous devez prendre en compte que lors de l'exécution par BIDS, le package prendra d'abord la valeur variable du fichier de configuration, et seulement si le fichier de configuration n'existe pas, il lancera un avertissement et la valeur sera prise du package.

Maintenant, la situation en ligne de commande est un peu différente. Vous pouvez avoir les situations suivantes:

  1. exécutez le package en ligne cmd sans aucun fichier de configuration choisi:

    dtExec /file "e:\Work\TestPackageConfiguration\TestPackageConfiguration\TestPackage.dtsx"
    • si le fichier de configuration d'origine (appelons-le Prod) n'existe pas dans le même chemin défini dans les métadonnées du package, les valeurs de l'intérieur du package sont utilisées et vous recevrez juste un avertissement indiquant que le fichier de configuration est manquant;
    • si le fichier de configuration d'origine existe et est valide, les valeurs du fichier de configuration seront utilisées (les valeurs internes seront ignorées);
  2. exécutez le package en ligne cmd sans aucun fichier de configuration choisi, mais avec une variable définie dans l'appel:

    dtExec /file "e:\Work\TestPackageConfiguration\TestPackageConfiguration\TestPackage.dtsx" /SET \Package.Variables[checkMe];"outside the package in cmd line"
    • si le fichier de configuration d'origine n'existe pas, la valeur est extraite de l'appel de package / SET;
    • si le fichier de configuration d'origine existe, la valeur est extraite du fichier de configuration et même le / SET est ignoré (ceci n'est utilisé que dans le cas ci-dessus);
  3. exécutez le package en ligne cmd avec un nouveau fichier de configuration (disons DEV à la place de Prod):

    dtExec /file "e:\Work\TestPackageConfiguration\TestPackageConfiguration\TestPackage.dtsx" /configFile "c:\ETL Config\TestPackage_config_Dev.dtsConfig"
    • si le nouveau fichier de configuration (Dev) existe, mais pas l'ancien (Prod), alors les valeurs qu'il contient sont utilisées;
    • si les fichiers de configuration Dev et Prod existent, alors seules les valeurs de Prod sont utilisées (DEV est contourné même s'il est spécifié dans l'appel de ligne de commande);
  4. exécutez le package en ligne cmd avec un nouveau fichier de configuration et une instruction SET dans l'appel:

    dtExec /file "e:\Work\TestPackageConfiguration\TestPackageConfiguration\TestPackage.dtsx" /configFile "c:\ETL Config\TestPackage_config_Dev.dtsConfig" /SET \Package.Variables[checkMe];"outside the package in cmd line - DEV config"
    • si les deux fichiers de configuration existent, Prod sera utilisé, tous les autres ignorés, même SET;
    • si aucun fichier de configuration n'existe, la valeur SET sera utilisée;

Donc, en bref, si vous souhaitez utiliser un nouveau fichier de configuration, vous devrez renommer / déplacer l'ancien et appeler le package avec / configFile. Si cela ne suffit pas et que vous souhaitez remplacer le nouveau fichier de configuration, utilisez la variable / SET. Ou vous pouvez contourner n'importe quel fichier de configuration et utiliser simplement les instructions / SET dans l'appel par lots.

J'espère que cela éclairera vos possibilités.

Marian
la source
Il semble donc que l'un des gros problèmes est que mon chemin sur la boîte de développement est identique à taht sur le serveur pendant l'exécution, de sorte que le chemin vers la configuration dans le package est toujours valide.
Cade Roux
Je pense donc que je devrais avoir Dev, Test et Prod, que le package pointe toujours vers Dev et ne jamais avoir de configuration Dev sur mon serveur et que je puisse ensuite faire plusieurs configurations sur le serveur et pouvoir exécuter différentes configurations à volonté depuis la La configuration de développement dans le package ne sera jamais trouvée. Je peux donc déboguer à l'aide de la configuration Dev, mais j'aurai ensuite du mal à l'exécuter à partir de la ligne de commande sur la boîte de développement, car il trouvera cette configuration.
Cade Roux du
Je suppose que vous convenez que c'est vraiment beaucoup plus complexe qu'il ne devrait l'être, non? Comme s'ils avaient obtenu une nouvelle petite fonctionnalité (le rechargement) dans le passage à 2008, mais ont tué le scénario d'utilisation le plus courant des configurations de package.
Cade Roux
Eh bien, OUI, je suis d'accord que c'est beaucoup plus laid qu'il ne devrait l'être. Il m'a fallu beaucoup de temps pour comprendre cela, car j'ai toujours oublié de renommer le fichier de configuration d'origine :-). J'aurais aimé qu'il soit plus dans l'ordre suivant: SET, / configFile, config d'origine, valeur du package interne. Cela aurait été plus logique pour moi ..
Marian
Aucun des articles que j'ai lus ne mentionne vraiment que c'est le fichier de configuration d'origine qui est accessible, ce qui pose beaucoup de problème. Maintenant, je vois pourquoi ils ont publié cet éditeur de package SSIS afin que vous puissiez changer cela dans le package sans avoir à ouvrir BIDS.
Cade Roux