I am trying to desing a series of SSIS packages that will read their
Connection Manager's connection string property from a package configurtion.
I anticipate databases migrating between servers in the near future and do
not want to re-design or re-enter connection strings, etc. I set up a single
database that holds all my SSIS configurations. One table has connection
strings that will be read by many packages.

My issue is this:

Suppose Package 1 uses Connection A and B, and I configure their connection
strings to come from a Configuration table as described above, then I get two
records in the table, one for each Connection, A and B. Now, suppose Package
2 uses Connection B and C. If I use the same table and same filter as is used
by Package 1, then when all is said and done, I end up with two records in
the table, this time for Connections B and C, but have lost the entry for
Connection A.

How do I make it so that it does not delete records that are not used by the
package when it sets up the configuration filter?

I suppose I could use a separate filter for each Connection, but with up the
6 connections in one package, that is a lot of repetetive work.

Another way would be to extract the records from the config table after rows
get added and compile them safely somewhere else, then, after all packages
have been configured, load the complete set back into the original table.
Again, this is exise!

Any suggestions out there?
Thanks in advance
--
Todd Chittenden

Hello Todd,

The reason you get an overwrite is because it asks you after selecting the
filter to either reuse existing or overwite. If you reuse existing you get
to set no more properties. There are a number of ways to skin your cat

1. Copy and paste in the connection details in manually. You would then
have the same configuration filter for all 3 connections (Easy)
2. Have two filters in there. This means you would set the connections
from different filters.



Regards

Allan Mitchell
Konesans Ltd
T +44 7966 476 572
F +44 2071 008 479
http://www.konesans.com

Based on the experiences in designing the packages, I chose to go with a
dedicated Filter for each COnnection Manager. Here's why:

1) If the filter contains entries for package elemets (Connection Managers)
that do not exist in the package, you get errors when openning the package in
design mode and errors when executing it. There errors, though not
show-stoppers, are bothersome.

2) You cannot pick and choose which Connections to hook up to Configurations
if you have all entries under one filter. Splitting up one Configuration per
Connection allows you to have a 'one-off' Connection if needed, say to a
prototype database.


--
Todd Chittenden


"Todd C" wrote: