1) Every package has to have its own configuration file? There's no configuration on a project level? 2) is there anything in particular I have to do with a configuration file before running a build? When I run deployed package it seems like it ignores my configuration file and takes the connection string of conn. manager i use in development.

Hi, This link might be of help to you: http://msdn2.microsoft.com/en-US/library/ms167153.aspx Hwo do you deploy and run your packages? -Bhargavi This posting is provided "AS IS" with no warranties, and confers no rights.

Sara,A package can reuse another's configuration file. You have to setup each package to look for the same named configuration file and enable package configurations.You shouldn't be building anything -- there's nothing to build. Either just copy the .dtsx package files to your server and the associated config files, or import the packages to SQL Server via Management Studio (or the File->Save Copy of XXXX As... option in BIDS)

Sara4 wrote: 1) Every package has to have its own configuration file? There's no configuration on a project level? 2) is there anything in particular I have to do with a configuration file before running a build? When I run deployed package it seems like it ignores my configuration file and takes the connection string of conn. manager i use in development. For 1) you should open up a dtsConfig file and see how the configuration is stored. You'll see something that looks like this: Code Block <Configuration ConfiguredType="Property" Path="\Package.Variables[User::ContinueExecutionOnFailure].Properties[Value]" ValueType="Boolean"> ... The key point is that you can reuse this configuration file with any package that has a variable with the same name and data type - and you can get the same sort of reuse with connection managers or any other components that are common across all configured packages. You basically just need to have each package be aware of the fact that there is a configuration, and have them all reference the same file, and then you define the configuration once with all packages pointing to it. For 2) it sounds like your packages may be looking in the wrong location when deployed. Do you use indirect configurations, where the path to the config file is stored in an environment variable? If so, you should verify that the environment variables are set properly and that the files you think are in a given location are in fact the filesthat are there. (I've made mistakes with this stuff enough times to never trust myself, even when I "know" I did it right.) Also, check your package warnings to ensure that the configurations are being set in the first place.It's also possible thatSSIS cannot find the environment variable and/orconfig file when the package is executed, so the values thatare in the package from development are being used instead. Good luck!

<?xml version="1.0" ?> - <DTSConfiguration> - <DTSConfigurationHeading> <DTSConfigurationFileInfo GeneratedBy="prev\user1" GeneratedFromPackageName="Package1" GeneratedFromPackageID="{0C5712C4-BFAD-45B6-A75D-E8C1BBCC9D29}" GeneratedDate="06/11/2007 15.14.52" /> </DTSConfigurationHeading> - <Configuration ConfiguredType="Property" Path="\Package.Connections[MyProject].Properties[ConnectionString]" ValueType="String"> <ConfiguredValue>Data Source=X3SQLSERV;Initial Catalog=DBTest;Provider=SQLNCLI.1;Integrated Security=SSPI;</ConfiguredValue> </Configuration> - <Configuration ConfiguredType="Property" Path="\Package.Connections[RiskMgmt.mdb].Properties[ConnectionString]" ValueType="String"> <ConfiguredValue>Data Source=F:\RiskMgmt.mdb;Provider=Microsoft.Jet.OLEDB.4.0;</ConfiguredValue> </Configuration> </DTSConfiguration> thatis my example config. file. So, if I add all of my connections as <Configuration ConfiguredType="Property" Path="\Package.Connections[MyProject].Properties[ConnectionString]" ValueType="String"> <ConfiguredValue>Data Source=X3SQLSERV;Initial Catalog=DBTest;Provider=SQLNCLI.1;Integrated Security=SSPI;</ConfiguredValue> </Configuration> in one config file, I should be OK? It doesn't metter that the attribute GeneratedFromPackageName="Package1" references one package of my is project?

It seems that I cannot create one config file for all of my packages because not all of them use the same connection managers. In other words, if I use a config file for a package that does not contain a certain connection manager specified in the config file, the package throws an error in loading. Is this correct?

Sara4 wrote: It seems that I cannot create one config file for all of my packages because not all of them use the same connection managers. In other words, if I use a config file for a package that does not contain a certain connection manager specified in the config file, the package throws an error in loading. Is this correct? That is correct. This is why it is recommended that you have more granular (one value per configuration) configurations. Otherwise, you need to ensure that each packagehas all of the components that are being configured.

MatthewRoche wrote: Sara4 wrote: It seems that I cannot create one config file for all of my packages because not all of them use the same connection managers. In other words, if I use a config file for a package that does not contain a certain connection manager specified in the config file, the package throws an error in loading. Is this correct? That is correct. This is why it is recommended that you have more granular (one value per configuration) configurations. Otherwise, you need to ensure that each packagehas all of the components that are being configured. ...Or you can use SQL Server table based configurations, where you can have all the configurations in a single table.

MatthewRoche wrote: Sara4 wrote: It seems that I cannot create one config file for all of my packages because not all of them use the same connection managers. In other words, if I use a config file for a package that does not contain a certain connection manager specified in the config file, the package throws an error in loading. Is this correct? That is correct. This is why it is recommended that you have more granular (one value per configuration) configurations. Otherwise, you need to ensure that each packagehas all of the components that are being configured. Another (not so pretty) approach is to include all the connection managers in each package. If you don't reference them from a task or data flow, they won't be used, but you don't see the warnings. It's not ideal, but it might be simpler than referencinga lot of config files.

...Or you can use SQL Server table based configurations, where you can have all the configurations in a single table. I've been trying the sql server configurations. It is all in one table, ok, in any case, much better than having n distinct config files. But,the basic problem remains the same - one package cannot use a configuration filter of another one if they do not use the same connection managers. Am I getting this right? I must say that this is a bit confusing since i'm expecting for the configuration file/tableto behave somewhat dynamicly. If a package does not containa connection manager I'm referencing in the configuration file why shouldn't the package just ignore it and use the configurations for the conn. managers that it uses?

There is now an open source utility available in CodePlex which can be used to batch update SSIS Package Configuration File paths without using BIDS or manually editing the package XML: http://ssisconfigeditor.codeplex.com/