February 10, 2014 at 8:54 am
I have a SSIS package that was moved from SQL 2005 to 2008 R2. The package was upgraded and it debugs fine. Deployed to Integration Services, it run fine. Execute the package by command line, it runs fine.... Schedule it as a job ... It says it ran, but it did NOT do a thing..
Has anyone ever run into this? I tried creating a test package and scheduling it as a job and it works fine... But this upgrade package doesn't run, even though it says it succeeded.
Please help... Any ideas on a fix is greatly appreciated.
February 10, 2014 at 2:22 pm
The post seems to indicate that you are running a SSIS package in a job - correct?
When you go to Job Activity monitor, right click the "completed" job and click on history and expand to look at the step, what does the step history say happened?
That's the first place to check.
If you need more help after that, we will need more details.
Thanks
John.
February 10, 2014 at 2:29 pm
Could the job be configured to exit and report success on failure?
February 10, 2014 at 2:53 pm
JohnFTamburo (2/10/2014)
The post seems to indicate that you are running a SSIS package in a job - correct?When you go to Job Activity monitor, right click the "completed" job and click on history and expand to look at the step, what does the step history say happened?
That's the first place to check.
If you need more help after that, we will need more details.
Thanks
John.
The message is as follows..
"Message
Executed as user: NA1\svc-sqlfact. The step succeeded."
It's just weird... Everything points to it running fine, you you know it didn't because it will run in a few seconds... If you run the package manually, it takes like 20 mins because of the number of records it needs to parse and load...
BTW, I also tried running the package from a command prompt. If I run it from a command prompt, it runs fine, just as if I ran it from BIDS or executed it manually from the Integrations Services... But if I save the command line to run it as a batch file, and set it up as a job to run the batch... it does the same BS... says it ran with success, but nothing actually ran...
February 10, 2014 at 2:55 pm
Matt Crowley (2/10/2014)
Could the job be configured to exit and report success on failure?
That was one of the 1st things I checked.. and it's setup right... to quit with success, if successful and to quit with failure, on failure action...
For all intent and purpose... The SQL Agent thinks it actually ran the package with success...
February 10, 2014 at 3:02 pm
Is there anything in the configuration of the job that runs depending on the logged in user? The only difference so far has been the Agent account running the job,and your ID running the job. Are there any conditional statements like "if the Z:\ drive is mapped"....
February 10, 2014 at 3:10 pm
Dae (2/10/2014)
The message is as follows.."Message
Executed as user: NA1\svc-sqlfact. The step succeeded."
It's just weird... Everything points to it running fine, you you know it didn't because it will run in a few seconds... If you run the package manually, it takes like 20 mins because of the number of records it needs to parse and load...
BTW, I also tried running the package from a command prompt. If I run it from a command prompt, it runs fine, just as if I ran it from BIDS or executed it manually from the Integrations Services... But if I save the command line to run it as a batch file, and set it up as a job to run the batch... it does the same BS... says it ran with success, but nothing actually ran...
1. Does NA1\svc-sqlfact have permissions to the SSIS server, and all of the resources that are to be accessed?
2. Did you check your SSIS connection strings, etc.?
3. Matt is correct -- is the drive mapping the same?
We still need more information to be helpful. Sorry, but it is what we need.
Thanks
John.
February 11, 2014 at 8:04 am
None of the drives are mapped... but we're pulling data from an Oracle server..
I tried using my logon, sa and one other and the same thing happens...
If it were an permissions issue, wouldn't it have generated an error?
I'm not sure where to look... But I'll ask the server admin to check permissions....
If anyone has any other idea, please let me know....
Thanks!
February 11, 2014 at 8:18 am
If there was a permissions error, it should return an error. However, errors can be caught. What kind of error handling is in the package, where are they logging to, and what status do they report?
Declaring a permissions error with no hard error message may be premature, though. You should look at any branching this package does before the main body of work, to see how this thing can be avoiding doing anything. What conditionals are tested before any loading or transformations?
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply