Конфигурации пакета служб SSIS 2008 игнорируются


10

С изменением конфигурации пакета в 2008 году по сравнению с 2005 годом, когда я указал / ConfigFile что-то.dtsConfig в командной строке, переменные, определенные в пакете, сохраняют свои значения времени разработки вместо использования параметров из файла конфигурации.

Я не совсем уверен, что понимаю, КАК получить внешний конфигурационный файл для использования вообще. Я читал статьи, в которых говорится, что только установленные во время разработки конфигурации перезаписывают загрузку внешнего файла. Означает ли это, что я могу изменить переменные на пустые строки, и тогда они будут перезаписаны? Я не могу удалить переменную полностью! Как насчет целых чисел?

Я видел статьи, в которых упоминается отключение с использованием конфигураций пакета в пакете.

Я могу использовать редактор пакетов служб SSIS или редактор XML, чтобы изменить путь к файлу конфигурации в пакете, а затем он будет использовать настройки этого файла «последними» (независимо от параметра external / ConfigFile), но я не хочу, чтобы смена пакета. Мне нужен один пакет с Test.dtsConfig и Production.dtsConfig, и я могу поменяться местами, не меняя пакет.

Каков рекомендуемый способ сделать это сейчас?


1
Вы можете найти свое облегчение здесь , на форуме SQLServerCentral. Некоторое объяснение изменения поведения находится здесь - раздел Изменения поведения, связанные с конфигурациями пакетов.
Marian

Пожалуйста, посмотрите следующие файлы, чтобы иметь представление о том, о каких пакетах и ​​конфигах я говорю: Конфиг и пакеты , Тестовый пакет и Readme .
Marian

Ответы:


10

Вы должны принять во внимание, что при запуске BIDS пакет примет сначала значение переменной из файла конфигурации, и только если файл конфигурации не существует, он выдаст предупреждение, и значение будет взято из пакета.

Теперь ситуация в командной строке немного другая. Вы можете иметь следующие ситуации:

  1. запустите пакет в строке cmd без выбранного конфигурационного файла:

    dtExec /file "e:\Work\TestPackageConfiguration\TestPackageConfiguration\TestPackage.dtsx"
    • если исходный файл конфигурации (назовем его Prod) не существует по тому же пути, который определен в метаданных пакета, используются значения внутри пакета, и вы просто получите предупреждение об отсутствии файла конфигурации;
    • если исходный файл конфигурации существует и является действительным, то будут использоваться значения из файла конфигурации (внутренние значения будут пропущены);
  2. запустите пакет в строке cmd без выбранного файла конфигурации, но с переменной, установленной в вызове:

    dtExec /file "e:\Work\TestPackageConfiguration\TestPackageConfiguration\TestPackage.dtsx" /SET \Package.Variables[checkMe];"outside the package in cmd line"
    • если исходный файл конфигурации не существует, то значение берется из вызова пакета / SET;
    • если исходный файл конфигурации существует, то значение берется из файла конфигурации, и даже / SET игнорируется (это используется только в описанном выше случае);
  3. запустите пакет в строке cmd с новым файлом конфигурации (скажем, DEV вместо Prod):

    dtExec /file "e:\Work\TestPackageConfiguration\TestPackageConfiguration\TestPackage.dtsx" /configFile "c:\ETL Config\TestPackage_config_Dev.dtsConfig"
    • если новый файл config (Dev) существует, а старый (Prod) нет, то используются значения из него;
    • если существуют оба файла конфигурации Dev и Prod, то используются только значения из Prod (DEV игнорируется, даже если это указано в вызове командной строки);
  4. запустите пакет в строке cmd с новым файлом конфигурации и оператором SET в вызове:

    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"
    • если оба конфигурационных файла существуют, будет использоваться Prod, все остальные игнорируются, даже SET;
    • если файл конфигурации не существует, будет использовано значение SET;

Короче говоря, если вы хотите использовать новый конфигурационный файл, вам придется переименовать / переместить старый и вызвать пакет с помощью / configFile. Если этого недостаточно и вы хотите переопределить даже новый файл конфигурации, используйте переменную / SET. Или вы можете обойти любой файл конфигурации и просто использовать операторы / SET в пакетном вызове.

Надеюсь, что это поможет пролить свет на ваши возможности.


Похоже, что одна из больших проблем заключается в том, что мой путь в окне разработки идентичен тому, что указан на сервере во время выполнения, поэтому путь к конфигурации в пакете всегда действителен.
Cade Roux

Поэтому я думаю, что у меня должны быть Dev, Test и Prod, пакет должен всегда указывать на Dev и никогда не иметь конфигурацию Dev на моем Сервере, и тогда я могу сделать несколько конфигураций на сервере и иметь возможность запускать разные конфигурации по желанию, так как Конфигурация Dev в пакете никогда не будет найдена. Так что я могу отлаживать, используя конфигурацию Dev, но тогда у меня будут проблемы с запуском его из командной строки в окне dev, потому что он найдет эту конфигурацию dev.
Cade Roux

Я полагаю, вы согласны, что это действительно намного сложнее, чем должно быть, верно? Как будто они получили новую маленькую особенность (перезагрузку) при переходе на 2008 год, но убили наиболее распространенный сценарий использования конфигураций пакета.
Cade Roux

Ну, да, я согласен, что это намного ужаснее, чем должно быть. Мне потребовалось много времени, чтобы понять это, потому что я всегда забывал переименовывать исходный файл конфигурации :-). Мне бы хотелось, чтобы это было в следующем порядке: SET, / configFile, исходная конфигурация, значение внутреннего пакета. Это имело бы больше смысла для меня ..
Marian

Ни одна из статей, которые я прочитал, не упоминает о том, что доступ к исходному конфигурационному файлу является большой проблемой. Теперь я понимаю, почему они опубликовали этот редактор пакетов служб SSIS, чтобы вы могли изменить его в пакете, не открывая BIDS.
Cade Roux
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.