I have an SSIS package, that worked just fine for months. It was planned in an SQL Agent Job, and launched every day, as the 8 step of the 23-steps job.
Then all out of nowhere (understand, with absolutely no changes), the said package/step, started returning a failure. But where it start becoming kind of weird, is that :
Launching the package in stand alone (from Visual Studuo or Execute Package Utility) is running as smooth as it can be.
Starting the SSA job from step 8, also return success.
Starting the SSA job from step 1, return a failure at step 8.
Thanks in advance for any idea you might have.
I solved (temporarily) the problem by editing the #retry_attempts propriety of the jobstep in SQL Server Agent. I've set it to 1 so it will repeat one time if there is a failure.
So after the test, there is still a failure on the first execution of the package, but the repeat works fine, which allow the job to continue "journey" without interrupting.
PS: It's definitely not a good, or even a satisfactory solution, mainly because I still don't know what the cause is. If you have any trails I can follow, please do not hesitate.
Related
I have job which has only one step. This step calls an SSIS package. Most of the time it is running fine however sometimes it is failing due to connectivity some issues.
It is very hard to track this kind of failure since when I open the job history (screenshot below) it shows the job is completed successfully. When I click on the step which I highlighted on the same screenshot I could see the error.
I have plenty of jobs like this and it is very hard to track these kind of errors manually.
The below is the actual error due to which the job step is failed however the overall job status showing it as success.
This is a weird scenario and impossible to track. We already have job failure reporting mechanism where it tracks only the over all job failure but it unable to track the Job step failures.
Logically speaking the overall status of the job should fail if one or more steps failed to complete. I have checked the Advanced option below looks like everything is fine. I am not sure where to start with. Please provide some insights on this.
I am trouble shooting an error in a package.
Update MYTABLE for MYCOLUMN (REF to task name):Error: Executing the query "..." failed with the following error: "Invalid column name 'MYCOLUMN'.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
I have verified the table and column exists, the length of the field is way excessive than what it needs that is 14 where it is declared as varchar(250).
I have verified the script works on the server in SSMS outside of the context of the package.
I have verified the connection and database in the package is as I expect.
Is there away to verify on the server. I did try to look at the Connection Managers tab on the package configuration itself i.e. in the Integration Services Catalogs->SSISDB->solutionfolder->..->package.dtsx->Configure context menu but it is empty.
Any ideas on how to troubleshoot?
Just to add more context the package contains 27 other tasks, 9 tasks in a row linked to this task but all set to on completion, all seem to be doing stuff independent of the other. 1 task is a loop doing stuff and the rest are single independent tasks. So I don't know at this stage if it is a cascading connection issue perhaps however; I am just reading what the log says.
I kicked off the package at 9:54am, the timestamp on the error log says 11:45am so nearly 2 hours into running is this log reported.
I would suggest the below things to troubleshoot the issue.
I would suggest you to just have this task and disable all other
tasks to troubleshoot the issue. So that you can focus on this issue
specifically. That will tell you whether connection is working fine
without issues.
I would suggest you to edit the task and see whether parameters are
set properly. Different providers have different way of setting
parameters. Again check whether parameters are proper. Execute SQL
Task
one more thing, may be you are pointing the package to different
connection than the one you used for SSMS. So, it is working in SSMS
and in the connection being used in the package is not having schema
changes yet done.
I finally figure it out before I read the previous offered suggestion so will give some credit if I can! FYI: We have a lot of dev servers. I clicked on the overview hyperlink in the All Execution logs and it said another server. Also I found the connection on the job calling the package not the package itself so I have learnt something today. Anyhow the job said one server but the overview said another so I again I was back to square one scratching my head.
Then I decided to open the connection manager on the job and select the field and make no change rather then cancelling I clicked ok not thinking about it and noticed the field changed to bold face. So I am assuming if you make a manual change on the server in SSMS to anything it shows up in bold which is kind of useful. So I can only assume this is a MS SSMS or SSIS or VS deployment bug. That it does not overwrite, the previous connection although the SSMS interface says otherwise. Perhaps somebody can share some light. Having not checked the server before I made a change and deployed it I have no idea if the previous settings were changed manually by someone or the connection in the package was changed and deployed. Anyhow checking the job history shows it had been failing for awhile so it wasn't me so whoever and whenever a change was done by a previous developer didn't figure it our either or didn't bother or did not know how, or didn't observe it. Anyhow it is pointing to the correct server now!!!
I have a package with one data flow task. In the data flow task it copies data from one database to another archive database.
I linked two precedence constraints. If it's successful it should go on and start a certain job in SQL Server (delete records from the original database). If the task fails, it should return a script task saying that it failed.
When I run this, the data flow task is successful (every record gets copied). The data flow task gets a green tick. The "execute SQL Server Agent Job Task" also gets a green tick. Yet after completing the package it says
"Package execution completed with error. Click here to switch to design mode, or select Stop Debugging from the Debug menu."
I included a screenshot of it:
The output basically only says:
SSIS package "c:\Users\Kim\Documents\Visual Studio 2012\Projects\POC\POC\Archive.dtsx" finished: Failure.
So:
Where can I find the error? There is no indication at all what went wrong. Both show green ticks and the migration of data did went well indeed. The SQL Server job didn't do its job. The records are still there. So I have a feeling that the error has to do with the job. I have to mention it is the Change Data Capture cleanup job which was automatically made when I turned on CDC on this table. I did this because I only want this job to happen when the data flow task is successful (instead of running the schedule by default).
If it failed, why didn't it follow the precedence constraint for failure (showing the script)?
SQL Server agent is turned on by the way.
Can someone please help me? I googled "Package execution completed with error" and I literally get only 68 results which are not helping.
Kim
I recreated the entire package and it completed with success. I'm still wondering what the difference is with my original package, but I'm guessing it might have something to do with non-corresponding meta-data. When making the original package I had copied a few tasks and then made new tasks and deleted the copied ones (because it was easier to look between them instead of switching between SSIS projects). I deleted all the old copied tasks, but possibly something went wrong there and that something is still linked to old metadata. All the tasks are performing though.
Mike en Ennor thanks for looking into the problem. If anyone has any clue what it could be, please reply anyway, because my solution to recreate the package again was not a satisfying solution.
Kim
Did you look at the Event Handlers? Also, any other failed configurations or Loggings in the background? These three could be possible culprits. Any other Tasks that are disabled and are using an old connection string that no longer resides on the package?
I got the same issue.
Try going through each event handler tab, data flow tab for Evey executable while in the execution / run mode. You would be able to see red Cross marks where the error is.
Run the workflow > click the "Progress" button to see red X's.
When I run my SSIS package in Visual Studio it executes just fine. However when I try to execute this same package using the SQL server agent, by either CmdExec or SSIS package type, it gets canceled. The package is stored on the IS catalog. All on the same server.
The standard report tells me task x failed, but is not showing any error messages. I'm sure there is nothing wrong with the task itself as after an DB restore and rerun of the same package with the same data, a different task fails.
I have tried this several times and it always fails because of 1 (out of possible 3) task which are more or less close to each other in the control flow. Moreover the task that fails is only calling a stored procedure, which is completely encapsulated with try-catch.
The standard report is however throwing the following message at the time the package failed:
< ?xml version"1.0"?> < DTS:ProcessMemoryUsage xmlns: DTS=www.microsoft.com/sqlserver/DTS">
< DTS:Peakworkingsetsize>320692224< /DTS.................
which makes me think it has something to do with memory. However can't find anything usefull on google about this message.
I already trying things for a week now but not able to find the solution. Please help?
It might something going on in your tasks. I have noticed the same behavior while running SSAS cube. If it fails, gives not specific error. Try to disable all tasks and enable them one by one in order to find which contains the problem.
I cannot find a similar question. I have an SSIS package that contains a visual basic script task with the following line in it - msgbox("some text") . It runs fine from BIDS and manually executed from MSDB, but when I schedule it in SQL Server agent the package seems to fun fine until that point and completes. But the message box does not appear and none of the actually tasks after that run. The scheduled job reports complete and success. Can you point me to the right solution, I believe it would have something to do with the SSIS proxy account and its security but can't find anything. Does anyone know how to resolve this?
Here's a snapshot of my code. As you can see, I'm firing off lots of message boxes in an attempt to log what steps are working withing my package.
xworkbook = ExcelObject.Workbooks.Open("C:\xxx.csv")
xworksheet = DirectCast(xworkbook.Sheets(1), Excel.Worksheet)
MsgBox("csv")
xworksheet.Range("B:B").Replace(What:=",", Replacement:="")
MsgBox("replace 1")
xworksheet.Range("B:B").Replace(What:=".", Replacement:="")
MsgBox("replace 2")
xworkbook.SaveAs("C:\xxx.xlsx", FileFormat:=51) MsgBox("saved")
I believe that the reason it won't work is that when you run the SSIS task as a scheduled job it doesn't run in the context of your account but rather the service account for the SQL Server Agent and the message box won't show for you. The messagebox isn't valid for a non-interactive task.
#jpw hit the nail on the head for "The messagebox isn't valid for a non-interactive task."
To make it work you either need to strip your message boxes out of your code or inspect the value of the boolean Variable System::InteractiveMode
Code approximately
If CBool(Dts.Variables("System::InteractiveMode").Value) = True Then
....
End if
Assorted references
Microsoft SQL Server 2008 Integration Services Unleashed
How do I disable interactive message boxes from inside an SSIS package?
You overcome this by changing your process so that no user intervention is needed. There is no reason you should ever have a message box in SSIS except for debugging.