Sunday, March 25, 2012

config creating havoc

I have created two package configurations

Each identical apart from the name (dev/prod) [They appear in that order in the 'configurations..' dialog]

I then manually edited the prod config (in notepad) to the correct values (connection string etc)

I then opened the config file in the config edit tool (some time later) to note that my changes had somehow been overwritten. I changed them back to the correct values and saved the prod config.

I then tried building the package.

It returned with numerous validation errors despite 'delay validation' being set to true on each of the tasks that were causing problems (they create temp tables which it cannot validate against)

I then tried running the package.

It errored.

It was trying to connect to production!!

How on earth is this possible?
According to the configuration dialog, the 'dev' configuration is the first one loaded.
I haven't told it anywhere to use 'prod'.
I haven't even (within ssis) managed to even change the values (connection strings) to production.

What is going on here?It would appear that subsequent entries in the 'package configurations organizer' overwrite initials ones.

e.g.
config1 value1=abc
config2 value1=def

the package would have value1=def

so, what exactly is the point of being able to load multiple configurations if it is just going to pick up the last one regardless?|||

The point of superceding configured properties, so far as I use it, to go from generalization to specialization.

A given configuration might be shared by 50 packages. However, for one or two of those packages, the configured value is not appropriate, must be specifialized, and hence, an "subclassed" configuration is added, which overrides the base, or precediing configuration.

|||ok, I can see how that could work but...

If I have a package and want to store the connection string for dev/test/prod in the same package, how can I then test this in VS.net?

Other than manually adding and deleting them each time?

also am getting the following error when trying to build:
Creating deployment utility...
Error : System.ApplicationException: Could not copy file "xxxx.dtsConfig" to the deployment utility output directory "yyyyyyy". > System.IO.IOException: The file 'xxxxxx' already exists.

I cannot see any kind of 'overwrite' flag in the project - deploy properties (like you get in reporting services)|||do not add config files into the misc folder in the project - this was causing the 'already exists' error

It obviously decides to deploy all the misc files. How stupid of me to include config files in this folder. They are only completely 100% relevant to the project after all.|||

You don't need to build anything, though. For that matter, deploying is a bit of a stretch as well. The .dtsx and .dtsconfig files are all you need. You can simply copy them to the server via a mapped drive, or use the import (or for that matter, Save Copy As... in BIDS) in Management Studio when connected to Integration Services if you prefer to store packages in MSDB.

As to your question as to dev, test, and prod, simply create three config files, name them slightly differently than each other. Then point your package to an environment-neutral named config file. To test, simply copy one of your dev, test, or prod config files (probably starting with dev) to the name that you have the package pointing to. When you want to switch environments, repeat the process using a different config file this time (perhaps test's file)

No comments:

Post a Comment