June 2, 2009 at 10:05 am
I've created and deployed a package on to a server that populates a data warehouse for me. However, I want to build another more complex package that relies on the data warehouse data being up to date before completing it's main tasks. I thought I could run the deployed package from the deployed File System package ensuring it will always be run before getting to the correct processing.
The deployed package is working fine at present on its own. When running it from an execute package task in my new "parent package" it fails giving the following error:
Error: Error 0xC0012050 while loading package file "\\gdt-sql02\e$\Program Files\SL Client Transfer\CopyClientFile.dtsx". Package failed validation from the ExecutePackage task. The package cannot run. .
In debug mode, this opens the child package when you run it for some reason. Looking at the execution results for the child package it looks like it fails on the password/username used in the data reader source (see start of error below):
[DataReader Source [1]] Error: System.Data.Odbc.OdbcException: ERROR [28000] [Sybase][ODBC Driver][SQL Anywhere]Invalid user ID or password ERROR [28000] [Sybase][ODBC Driver][SQL Anywhere]Invalid user ID or password at System.Data.Odbc.OdbcConnection.HandleError(OdbcHandle hrHandle, RetCode retcode) at System.Data.Odbc.OdbcConnectionHandle..c
I don't know why there's a password issue here as, according to a few postings I've seen, it states you should leave the Password field as it was in the execute package task editor unless you set a password against the child package, which I haven't done.
On opening the original package (the child) in BIDS, or by running the package from SQL Agent, this has now stopped working as well. Not sure whether the parent child package has corrupted the deployed package.
Any ideas anyone?
June 3, 2009 at 3:55 am
How have you configured the child package?
One of the limitations of calling the child package from the parent package using the Execute Package Task is that you can't specify configuration values for the child package.
Have you tried the Execute Process Task, using the DTEXEC command to execute the package? This task gives you the ability to specify an argument for the package and list the configuration files required to run the package.
June 3, 2009 at 4:20 am
Haven't used a configuration file for the child package actually. With the child package not working either, I'm thinking it may have something to do with that package instead. Problem is I don't know why it's stopped working as a result of adding it in as an execute package in the parent. I would have thought the original development version wouldn't be touched.
June 5, 2009 at 8:29 am
Anyone have any ideas on this or have come across a similar issue?
June 5, 2009 at 8:51 am
Do I have it right that the originally deployed package fails in BIDS or in SQL agent, but it will still run successfully via dtexec? If so, are all of the run methods using the same user credentials?
I've not seen a case where a parent package has corrupted a child package before. Have you verified that there are no permission or network issues that are affecting your obdc connection?
June 5, 2009 at 10:11 am
I'm still trying the execute package solution rather than moved on to running it in dtexec. It fails in BIDS, but I have a sql agent job that runs the deployed package and that's stopped working now as well, which is a bit more critical as the team I support rely on that one. The SQL Agent job runs as a different user but uses the same dsn connection setup.
I can test the odbc dsn connection in admin tools data sources (ODBC) and it connects. I also set up a test package in BIDS to connect to the same data source and that connects fine, so it's a mystery why my other two packages don't work (child on its own, and parent running child).
June 5, 2009 at 11:26 am
When the SQL Agent job fails, is it throwing the same odbc error as when it fails in BIDS? Are there any events in your server error log that might indicate an authorization failure?
Sorry, but I'm not sure why it's giving you the grief that it is, I'm just trying to run through all of the steps that I would if it were happening to me. None of my connections use odbc, they're all OLE DB or ADO.NET.
June 8, 2009 at 4:46 am
Yes, the same authorisation error I have in BIDS.
It's the ADO.NET connection I've used here. It's New ADO.NET connection > .Net Providers\Odbc Data Provider connection.
June 9, 2009 at 9:32 am
Worked out what this was in the end. I had set up the Ado.net connection in the connection manager area and it kept on losing the password for the odbc connection. Setting up a data source in the solution explorer window seems to have retained the password. Seems a bug to me.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply