I recently spent a morning debugging why a SQL job that executed an SSIS package wasn't working correctly when I ran it, but when I ran the package through BIDS it worked correctly. Turns out the problem was a misspelling in the configuration file name in the job. When I ran the package through BIDS, I was providing the correct variable values, and since one of the config files was missing, a critical variable had a null value in the job. While this was 100 percent my dumb fault, it got me thinking about an inconsistency in how SSIS handles configuration files. If I create a SQL jobstep that executes a package, and I provide a /CONFIGFILE parameter that doesn't exist, the job continues on its merry way without alerting me. If, however, the config file does exist but happens to contain a variable the package does not reference, the job bombs saying it can't load the config file. That seems inconsistent to me. Unless, of course, I'm a bonehead and completely missing something, which is well within the realm of possibility.

Absolutely not boneheaded - You do have a couple of options - the first being in BIDS keep the default settings blank (configure with a variable and leave the variable blank forcing it to configure or fail). The other option which we do is to use different accounts per environment. ie. we have a different proxy account for Dev/Test/Prod on the jobs - so if it doesn't configure correctly and connects to the wrong data source it will fail as well since it doesn't have permissions.

I suppose it's just irritating to me because when SSIS first came out, if you had a config file that had 10 variables in it and the package only used three of them, the system didn't care and just ignored all the other variables. Then the second version came out, and all of a sudden, you couldn't have variables in your config file that weren't in the package, meaning you either had to (a) have every package in your ETL reference all the possible variables (making debugging a nightmare) or (b) create and maintain a config library and make sure all your SQL jobsteps only referenced the applicable config files they needed (making job setup more of a pain). We went with option (b), so it bugs me that they went out of their way to prohibit what I was doing but there doesn't seem to be a failsafe when you reference a file that isn't there.