I have an SSIS job that is pumping to a SQL Server Destination, hundreds of gigabytes of raw text files. Today I received this strange error - does anyone have insight? Also, how would I make the data tasks more stable and robust so that this doesn't cause package failure (retries, or something?)

[SQL Server Destination [4076]] Error: An OLE DB error has occurred. Error code: 0x80040E14. An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80040E14 Description: "Cannot fetch a row from OLE DB provider "BULK" for linked server "(null)".". An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80040E14 Description: "The OLE DB provider "BULK" for linked server "(null)" reported an error. The provider did not give any information about the error.". An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80040E14 Description: "Reading from DTS buffer timed out.".

lowering the maxcommitsize on the SQL destination seems like it fixed this problem.

lowering the maxcommitsize on the SQL destination seems like it fixed this problem.

This is the error you get when you are attempting to load to a remote server. Are you executing the package on the same server that you are inserting to?

-Jamie

I have been getting this error myself and the only way to resolve it I have found is to delete your Source and Destination and in my situation Lookup Transformation. One thing I have noticed using any drag and drop in VS or SQL 2005 is it tends to cache old values and properties. I hope this helps for anyone else getting this error.

Thank you,

Brian

www.dealerbrand.com
www.razzari.com

The part of the error that refers to a "linked server" is totally bogus. I have seen this so many times when I am doing a local transformation, that this error is obviously a catch all which happens many different scenarios. As far as having to deletea bunch of transformations fot this error to go away - that is just unacceptable. (I know you are just the bearer of bad news, but there has to be a better way to deal with this error.)

dcb99

Hi, We are facing a similar issue.

We are migrating our production environment from 32-bit SQL Server 2005, Windows 2003 server to 64-bit SQL Server 2005, Windows 2003 server environment with 4GB of RAM. We have recompiled the SSIS packages to run in 64-bit mode and stored in database. The packages work fine when we execute them directly from Integration service engine but if we call & execute the package from a job, it fails with error message as

An OLE DB error has occurred. Error code: 0x80040E14. An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80040E14 Description: "Cannot fetch a row from OLE DB provider "BULK" for linked server "(null)".". An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80040E14 Description: "The OLE DB provider "BULK" for linked server "(null)" reported an error. The provider did not give any information about the error.". An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80040E14 Description: "Reading from DTS buffer timed out.".

~ Amit

What kind of destination are you using? If you are using a SQL Server Destinationset the "timeout" property to 0. If you are using the Ole Db Destination, then try some kind of different setting for CommandTimeout. Otherwise, look to see if there is some blocking on the destination table going on which would prevent an insert.

I came accross the same problem and the eventual solution for me was to change the timeout of the connection to the error logging table. I had two tables, one for the data and one for capturing errors, althoughthere were no errors in the import procedure, the procedure itself took over 30s to complete and this resulted in an error for the package.

Thanks for the usefull posts. In my case, this error was due to Format issue with source datasource text file. I did not specify correct delimiter in Bulk Insert Task component. So, do check that also.

Hope it helps someone

For whatever it's worth to future readers, I too solved this error by reducing the size of the SQLDestination's MaxInsertCommitSize.