SSIS Error Code DTS_E_OLEDBERROR.  An OLE DB error has occurred. Error code: 0x80004005.
My SSIS package runs fine when I run it from my workstation. But when I atttempt to run it in Production as user OPER it gives me this error: Error: 2012-01-31 09:01:54.03 Code: 0xC0202009 Source: Add to Accounting_Triton_Other (ATO) OLE DB il17a [1] Description: SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80004005. An OLE DB record is available. Source: "Microsoft JET Database Engine" Hresult: 0x80004005 Description: "The Microsoft Jet database engine could not find the object 'il17a1211'. Make sure the object exists and that you spell its name and the path name correctly.". End Error Error: 2012-01-31 09:01:54.03 Code: 0xC020204A Source: Add to Accounting_Triton_Other (ATO) OLE DB il17a [1] Description: Unable to retrieve column information from the data source. Make sure your target table in the database is available. End Error I've tried make a SQL Server Agent Proxy account and running it using that account. I get similar results but the error changes a bit. The job history shows this: An OLE DB record is available. Source: "Microsoft JET Database Engine" Hresult: 0x80004005 Description: "'U:\Valuation\Val1211files\' is not a valid path. Make sure that the path name is spelled correctly and that you are connected to the server on which the file resides.". I'm trying to import Visual FoxPro tables into Sql Server with this package.
February 2nd, 2012 9:05am

U: is probably a mapped drive. You cannot use it. Moral is, use the UNC paths (fully qualified).Arthur My Blog
Free Windows Admin Tool Kit Click here and download it now
February 2nd, 2012 10:48am

I put the UNC in and still get the same error (\\server\dir1\dir2\Valuation\Val1211files\ is not a valid path). When these packages are run from the server as a job do they have the access rights of the "Owner". I put my user name as the Owner. I'm wondering if there is a SQL Server user that runs the process and thta user can't see that path.
February 2nd, 2012 12:52pm

The the account executing does not have permissions over the file system.Arthur My Blog
Free Windows Admin Tool Kit Click here and download it now
February 2nd, 2012 12:56pm

You're right. I logged into the server and can't see that location. It's a mixed environment of Netware and Windows.
February 3rd, 2012 5:39am

I moved the files to the server that SQL Server runs on. I'm now getting this error: Started: 11:21:22 AM Error: 2012-02-03 11:21:29.63 Code: 0xC0202009 Source: Add to Accounting_Triton_Other (ATO) OLE DB il17a [1] Description: SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80004005. An OLE DB record is available. Source: "Microsoft JET Database Engine" Hresult: 0x80004005 Description: "The Microsoft Jet database engine could not find the object 'il17a1211'. Make sure the object exists and that you spell its name and the path name correctly." Again, it runs fine from my local machine. I'm looking at the protection level and seeing if changing that will help. I'm wodering if the server doesn't have the correct driver or if its a 64-bit vs 32-bit problem. On my PC I'm running the 32-bit version of dtexec. I'm not sure which version is running inside SQL Server management Studio.
Free Windows Admin Tool Kit Click here and download it now
February 3rd, 2012 10:09am

If it was a bitness problem you'd see different messages. A protection level problem wouldn't let you get this far. It's likely still a permissions issue. You're running this as an Agent job, or if otherwise, how? Agent jobs run under the service account (I believe - the other guys here know better), so you should usually configure up a "proxy" account for the job to use. To test (but NOT for production) you can set up a proxy to YOUR account for the Job to use for that step. That'll guarantee it has the same rights as you. (Which is one reason why you don't want that setup in production.) Talk to me now on
February 3rd, 2012 11:59am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics