Можно ли для разных пакетов использовать один .dtsConfig файл

slishnevsky

[quot Mr Marmelad][quot slishnevsky] Я вообще то думал что это настолько естественно - хотеть иметь один конфиг файл на несколько пакетов а не 1000 конфиг файло для 1000 пакетов. Странно что никого больше этот вопрос даже не интересовал... ;(

Можно, например, в SQL Job каждого пакета указать явно конфигурационный файл.
У меня для девелопмента и тестирования один файл, для продакшн - другой

Бутенко Андрей

slishnevsky [quot Mr Marmelad][quot slishnevsky] Я вообще то думал что это настолько естественно - хотеть иметь один конфиг файл на несколько пакетов а не 1000 конфиг файло для 1000 пакетов. Странно что никого больше этот вопрос даже не интересовал... ;( Можно, например, в SQL Job каждого пакета указать явно конфигурационный файл. У меня для девелопмента и тестирования один файл, для продакшн - другой

Андрей, дело не в этом!
Вопрос в другом:

Можно ли для разных пакетов использовать один .dtsConfig файл

slishnevsky

Мой вопрос предельно прост - я могу использовать один конфигурационный файл для разных пакетов или нет? См. мой первый пост для примера.

Предположим имею 3 пакета Package1, Package2, Package3.
Во всех трёх пакетах имеется одна и та же SQL Server Connection.
В Package2 имеется так же Excel Connection.
В Package3 имеется так же Flat File Connection.

Если я создам 3 конфигурационных файла:
Packages.dtsConfig (в нём будет только SQL Server Connection, общая для всех).
Package2.dtsConfig (в нём будет только Excel Connection)
Package3.dtsConfig (в нём будет только Flat File Connection)

Тогда я могу указать:
Для Package1: Packages.dtsConfig
Для Package2: Packages.dtsConfig + Package2.dtsConfig
Для Package1: Packages.dtsConfig + Package3.dtsConfig

Таким образом всё работает, но очень громоздко, особенно, если пакетов не 3 а гораздо больше, много конфигурационных файлов.

А можно ли как то сделать так что бы был всего один конфигурационный файл Packages.dtsConfig для всех пакетов? Чтобы в нём можно было определить все Connections и Properties для всех пакетов?

То что врыжную можно туда вписать всё что угодно, но заходя в дизайн пакета, в раздел Package Configuration, лезут ошибки о несоответствии содержимого Packages.dtsConfig файла с параметрами и Connections самого пакета.

Заранее спасибо.

Можно.
Неужели так сложно проверить?
Наводка - в пакете ведь можно задавать несколько конфигов.

tpg

Можно. Неужели так сложно проверить? Наводка - в пакете ведь можно задавать несколько конфигов.

Как?

slishnevsky,

Вы правы, дизайнер не принимает избыточные конфигурационные файлы, так как они не соответсвуют схеме, которая валидирует xml-ну каждый раз при открытии пакета в студии.
Как отключить валидацию не знаю, да и не зачем.
Остаются следующие варианты несколько способов:

избыточное конфигурирование соедидений в каждом пакете. Самый простой способ - один dtsConfig, но и самый трудоемкий при изменениях

читать конфигурацию из базы, что и было предложено выше и является наиболее типичным примером. Но если одни пакеты берут данные только из Excel, а другие пакеты из базы, то необходимо добавлять избыточное соединение и инициализацию переменных в каждом пакете, что является частным соучаем предудущего решения

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

slishnevsky

tpg Можно. Неужели так сложно проверить? Наводка - в пакете ведь можно задавать несколько конфигов. Как?

Я изменил свой предыдущий пост - читайте последнюю фразу.

Бутенко Андрей

slishnevsky, Вы правы, дизайнер не принимает избыточные конфигурационные файлы, так как они не соответсвуют схеме, которая валидирует xml-ну каждый раз при открытии пакета в студии. Как отключить валидацию не знаю, да и не зачем. Остаются следующие варианты несколько способов: избыточное конфигурирование соедидений в каждом пакете. Самый простой способ - один dtsConfig, но и самый трудоемкий при изменениях читать конфигурацию из базы, что и было предложено выше и является наиболее типичным примером. Но если одни пакеты берут данные только из Excel, а другие пакеты из базы, то необходимо добавлять избыточное соединение и инициализацию переменных в каждом пакете, что является частным соучаем предудущего решения генерировать множество конфигурационных файлов с помощью простенькой программы, которая дергает конфигурацию из централизованного набора параметров в соответсвии с каждым пакетом или его шаблоном. В этом случае вы получаете дополнительную свободу, так как нет нужды тянуть на продакшин базу данных, к тому же у вас может быть много тест/продакшин конфигураций, которые можно отделить от пакетов, что с точки зрения архитектуры является самым правильным решением.

Меня интересует только один вариант - много пакетов один конфиг файл с настройками для всех пакетов.

Я не понимаю почему это невозможно.

На базе моего примера, я вручную могу создтаь файл, в котором будет:
SQL Connection
Excel Connection
Flat File Connection

Но прикрепить его ка пакетам я не могу - сыплет ошибками.
Почему они не сделали так чтобы можно было иметь один конфиг файл для разных пакетов.

На мой взгляд - это бред, это равносильно тому что бы иметь по отдельному Web.config-у для каждой ASPX странички в веб прикожении. Я не вижу разныцы.

slishnevsky,

Повторю ещё раз, меня НЕ интересует "много конфиг файлов на один пакет",
меня интересует "один конфиг файл на много разных пакетов".

Неужели так сложно прочитать внимательно то что я пишу, попытайтесь подумать секунду, прежде чем отвечать. Вы видите то что у вас вертется в голове, но не то что я пишу.

Итак, по новой:

slishnevsky

Предположим имею 3 пакета Package1, Package2, Package3. Во всех трёх пакетах имеется одна и та же SQL Server Connection. В Package2 имеется так же Excel Connection. В Package3 имеется так же Flat File Connection. Если я создам 3 конфигурационных файла: Packages.dtsConfig (в нём будет только SQL Server Connection, общая для всех). Package2.dtsConfig (в нём будет только Excel Connection) Package3.dtsConfig (в нём будет только Flat File Connection) Тогда я могу указать: Для Package1: Packages.dtsConfig Для Package2: Packages.dtsConfig + Package2.dtsConfig Для Package1: Packages.dtsConfig + Package3.dtsConfig Таким образом всё работает, но очень громоздко, особенно, если пакетов не 3 а гораздо больше, много конфигурационных файлов. А можно ли как то сделать так что бы был всего один конфигурационный файл Packages.dtsConfig для всех пакетов? Чтобы в нём можно было определить все Connections и Properties для всех пакетов? То что вручную можно туда вписать всё что угодно, но заходя в дизайн пакета, в раздел Package Configuration, лезут ошибки о несоответствии содержимого Packages.dtsConfig файла с параметрами и Connections самого пакета. Заранее спасибо.

slishnevsky

Итак, по новой...

Ещё раз - такое можно сделать, если у вас пакеты, с точки зрения конфигов, абсолютно одинаковы - конфигурируют одни и теже коннекты, переменные и т.п..
Если есть какие-то отличия, то единственный способ - использование нескольких конфигов. Например, у вас в трех пакетах есть коннект к одному и тому же экземпляру сиквеле и к одной же базе - есть смысл этот коннект оформить одним конфигом.
Если же у вас в каком-то пакете есть потребность сконфигурировать и другие объекты, которых нет или они кофигурируются по другому, то засунуть всё это в один и тот же конфиг не получится, придется делать дополнительные конфиги.
Да и гемморой всё это, ИМХО!
Почему вам не использовать следующую схему конфигурирования пакетов: делается один для всех пакетов конфиг файл, в котором сконфигурирован сиквельный сервер на котором же буду размещаться конфигурационные же таблицы. Соответственно, у вас в каждом пакете должно быть минимум два конфига - ПЕРВЫЙ показывает сервер с конфигурациями, второй уже конфигурирует, в соответствие с настройками из сервера конфигураций, сам пакет.
И поверьте на слово - это гибко и работает.