September 8, 2011 at 9:21 am
Already saw that MSDN post last week. As I mentioned it in the first post of this thread, I didn't find anything when I searched for it.
Unfortunately, I can't use DSNs to solve a problem that only exists when running the package via a job. The package runs fine in SSMS when I right click and run it. It does not run fine in the job, even after the 2008 upgrade.
Fortunately, I just figured out what the problem is and it's one of those "why didn't I check this first" issues. The connection string is in an XML config file, which still has client 1 listed instead of client 10.
Why didn't it switch until I changed the connection manager name? Well, because the new Server.Database connection wasn't in the config file. Only when I renamed it to match the config file's connection manager did it change.
I can't believe I've spent all that time knocking my head against this wall. Sometimes it's the simple things that get you.
September 8, 2011 at 9:22 am
Did you execute(debug) your package manually in 2008?
Please check again all connection manager ...(not only OLE-DB Connection manager) and use 2008 connection manager.... and try...
Thanks
September 8, 2011 at 9:22 am
Jack Corbett (9/8/2011)
You don't have a package configuration somewhere that is overwriting the design-time value do you? It sounds like that could be it since having a different name makes it keep the design-time setting.
That is exactly what my issue is. I changed the config file and tried re-running the job. Guess what? It works. DOH.
September 8, 2011 at 9:58 am
Brandie Tarvin (9/8/2011)
Jack Corbett (9/8/2011)
You don't have a package configuration somewhere that is overwriting the design-time value do you? It sounds like that could be it since having a different name makes it keep the design-time setting.That is exactly what my issue is. I changed the config file and tried re-running the job. Guess what? It works. DOH.
I think it's funny that I posted this at the same time you were posting that you had found that this was the issue.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
September 8, 2011 at 10:35 am
Jack Corbett (9/8/2011)
Brandie Tarvin (9/8/2011)
Jack Corbett (9/8/2011)
You don't have a package configuration somewhere that is overwriting the design-time value do you? It sounds like that could be it since having a different name makes it keep the design-time setting.That is exactly what my issue is. I changed the config file and tried re-running the job. Guess what? It works. DOH.
I think it's funny that I posted this at the same time you were posting that you had found that this was the issue.
I'm just glad I'm not the only one with these types of issues. Most aggravating one I've had so far was when I inadvertently created a local and global variable with the same name, one within the foreach loop and one package-wide. Spent a week trying to figure it out, bugged everyone I knew, screenshots and posts galore, only to have to broadcast my gaffe as the explanation.
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
September 8, 2011 at 6:16 pm
Glad you resolved the issue
But not a bug in my opinion, bad design perhaps, if I'm understanding your post correctly.
This is how SSIS Configurations have worked since 2005 version.
When you make config/connection changes in BIDS they are available for testing local.
Config changes are not made to the manifest/config files / dtsx files until you force the
changes via the SSIS Package Configurations Organizer.
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply