August 1, 2024 at 8:14 pm
We've got a third party app that runs on SQL Server 2008 R2. There's a SQL Job which runs two SSIS packages. (I am not a DBA, and I don't know how to develop SSIS.) Anyway, this SQL Job has been failing for a few days, but there's no error in the job's history. From it's point of view, everything is fine. But if I open the latest history and look at it, I'll see this:
Started: 7:05:06 AM
Error: 2024-08-01 07:05:31.87
Code: 0xC0047062
Source: Validate Addresses in LabELRHold Call Address Validation Web Service [361]
Description: System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.SqlServer.Dts.Pipeline.ScriptComponentHost.HandleUserException(Exception e)
at Microsoft.SqlServer.Dts.Pipeline.ScriptComponentHost.ProcessInput(Int32 inputID, PipelineBuffer buffer)
at Microsoft.SqlServer.Dts.Pipeline.ManagedComponentHost.HostProcessInput(IDTSManagedComponentWrapper100 wrapper, Int32 inputID, IDTSBuffer100 pDTSBuffer, IntPtr bufferWirePacket)
End Error
So, why doesn't that show as an error in the SQL Job's history?
Kindest Regards, Rod Connect with me on LinkedIn.
August 1, 2024 at 9:28 pm
This is one of the reasons why I generally don't care for "Try/Catch" in code in relation to jobs and database code. If people don't write it correctly, the calling code will never know there was a failure or may log something somewhere and still not cause an error. Even if it does, it's still possible on jobs to identify what actions need to be taken for each step including jumping to other steps. If the final step they're jumped to isn't setup correctly, the job may never fail.
A whole lot of "third party database/SSIS 'apps' " fall into such a category.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 1, 2024 at 10:36 pm
SSIS doesn't do a great job of logging by default.
These might help:
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply