Конфигурации пакета служб 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.