Deployment Of SSIS With Config Files

I went through other threads and links on this subject. Still one thing which concerns me is the config files.

My current folder path is C:\Karunakaran\folder1\folder2\

Under folder2 I have the following files

4 dtsx files
1 .database file
1 .dtproj file
1 .dtproj.user file
1 .sln file
1 .suo file

Config folder ( C:\Karunakaran\folder1\folder2\Config\)
common.dtsConfig
oracle.dtsConfig

Based on some of the threads, when I enabled package configuration, I changed the path from
C:\Karunakaran\folder1\folder2\Config\common.dtsconfig -> common.dtsconfig

Once I did this, when I open the project I get a dozen of warning similar to the one below

Warning loading <package1>.dtsx: Failed to load at least one of the configuration entries for the package. Check configurations entries and previous warnings to see descriptions of which configuration failed.

What am I doing wrong here? If I have to deploy this to another box, what should I do to ensure that nothing breaks once its copied / installed?

Thanks

wouldn't you need \config\common.dtsconfig ? (since it isn't in the root folder?)|||You should always use absolute paths. Always. With that said, the best way to make the path portable is to use environment variables to store the base path. Then you can use the environment variable in the package configurations dialog to specify where to store the file.|||

EWisdahl wrote:

wouldn't you need \config\common.dtsconfig ? (since it isn't in the root folder?)

I did tried that earlier, when I give \Config\Common.dtsConfig i was getting the following error.

ADDITIONAL INFORMATION:
Could not find a part of the path 'C:\Config\Common.dtsConfig'. (mscorlib)

Thanks

|||

Phil Brammer wrote:

the best way to make the path portable is to use environment variables to store the base path. Then you can use the environment variable in the package configurations dialog to specify where to store the file.

I dont think Sys Admin will allow the usage of environment variables, looks like absolute path is the only way for me.
Looks like Microsoft should do something about the config files issues.

Thanks|||I'm not sure there are any issues. Besides, you can always use SQL Server based configs.

Using relative paths has a whole host of problems, when considering, depending on where dtexec is executed from, the root path could be different that what you are expecting.|||

But this also does not give me flexibility of where I want to store my config file.
The other problem I have noticed is that I cannot use one single config file for all my packages, causing a maintanence issue.

I have not tried Sql Server based config, let me try it and see.

Thanks

|||You can use one config file for numerous packages. No problem.|||I prefer SQL Server configs, for exactly the reasons you are describing. The only catch I have found with them is setting the initial connection to the database that stores the configurations. I like using a single environment variable to store that connect string, but you can also use the connection switch of DTEXEC to set it.|||

Phil Brammer wrote:

You can use one config file for numerous packages. No problem.

I'm not able to.

I can do that, ONLY if all my packages have all the variables, connection managers defined in the config file, else it throws errors / warnings whenever I open up the package.

Thanks|||There have been a few posts on this recently. You can create all your connection managers in every package (if you don't use one in the package, it doesn't cause any problems) or you can set variables through the configuration, and set the connections based on expressions that use the variables.|||I going to try with both. But I think this looks more a work around.
I hope MS address this issue.

Thanks|||

Karunakaran wrote:

I going to try with both. But I think this looks more a work around.
I hope MS address this issue.

Thanks

No, I'd consider this "best practices."

If you feel, though, that this is a bug, then please post a submission on the Connect site: http://connect.microsoft.com/sqlserver/feedback

|||I'm not sure if this is a bug,but I'm sure this flexibility is required, especially if there are multiple packages, and when developer has no access to the prod env.

Thanks
|||

With regards to best practice:

I can't see how to use configuration in the case of branching using source control without manually changing the path for every branch.

And even worse if the files are checked out to different folders then the config will not work with an absolute path.

Storing configuration on the SQL server would also be difficult to use when using source control especially if you are working on local databases.

Do any of you have a good solution to using SSIS with source control and branching?