DTS_E_OLEDBERROR. Error code: 0x80004005.Difference between SQl Native client and oledb provider for sql server

Question

There was a communication link error while I was using SQL Server Native Client 10 in an SSIS Data Flow component.

Error: SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80004005. An OLE DB record is available. Source: "Microsoft SQL Server Native Client 10.0" Hresult: 0x80004005 Description: "Communication link failure".An OLE DB record is available. Source: "Microsoft SQL Server Native Client 10.0" Hresult: 0x80004005 Description: "TCP Provider: The specified network name is no longer available.

So I changed from SQL Server Native Client 10 to Microsoft OLEDB Provider for SQL Server, hoping that it would run fine. This time got an error as shown below:

[Transacn_Tbl1[737]] Error: SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80004005. An OLE DB record is available. Source: "Microsoft OLE DB Provider for SQL Server" Hresult: 0x80004005 Description: "Unspecified error occurred on SQL Server. Connection may have been terminated by the server.".

[Transacn_Tbl1[737]] Error: SSIS Error Code DTS_E_INDUCEDTRANSFORMFAILUREONERROR. The "input "OLE DB Destination Input" (750)" failed because error code 0xC020907B occurred, and the error row disposition on "input "OLE DB Destination Input" (750)" specifies failure on error. An error occurred on the specified object of the specified component. There may be error messages posted before this with more information about the failure.

What is the difference between these 2 providers? Which one should I use?

Answer 1

I ran into this issue after releasing a new SSIS project to the production environment.

At first, I was able to validate the package with success, but when I tried to execute the package, I got the DTS_E_OLEDBERROR. Error code: 0x80004005. message.

I tried to validate the package with the servername and password variables set to sensitive, but in this case the validation failed as well.

After setting the environment variables back to non-sensitive again and inserting the environment variable values, I was able to validate and execute the package.

To me it seems like in some cases the metadata in the SSISDB gets corrupted, but unfortunately I've not been able to point down the source of this issue.

I hope this will help someone. I've went through a lot of debug scenarios before I ended up with this (rather unsatisfying) solution.