none
SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80004005.

    Question

  • 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.

    Thursday, February 02, 2012 5:01 PM

Answers

  • 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.)


    Todd McDermid's Blog Talk to me now on

    Friday, February 03, 2012 7:55 PM
    Moderator

All replies

  • U: is probably a mapped drive. You cannot use it. Moral is, use the UNC paths (fully qualified).
    Arthur My Blog
    Thursday, February 02, 2012 6:43 PM
    Moderator
  • 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.

    Thursday, February 02, 2012 8:47 PM
  • The the account executing does not have permissions over the file system.
    Arthur My Blog
    Thursday, February 02, 2012 8:51 PM
    Moderator
  • You're right. I logged into the server and can't see that location. It's a mixed environment of Netware and Windows.
    Friday, February 03, 2012 1:35 PM
  • 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.

    Friday, February 03, 2012 6:05 PM
  • 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.)


    Todd McDermid's Blog Talk to me now on

    Friday, February 03, 2012 7:55 PM
    Moderator