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
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:
<
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 files that 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 that SSIS cannot find the environment variable and/or config file when the package is executed, so the values that are in the package from development are being used instead.
Good luck!
< xml version="1.0" >
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
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 package has all of the components that are being configured.
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 package has 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.
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 package has 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 referencing a 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/table to behave somewhat dynamicly. If a package does not contain a 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