none
Excel Data Source SSIS AcquireConnection failed 0x80004005 unspecified error

    General discussion

  • Nuances of using Excel data sources with SSIS

    Your Development Machine Setup

    • Needs Jet Drivers, available along with the default Office install so if you have Excel working fine locally, this is enough.
    • Installing the "Office Data Connectivity Components" (download file name AccessDatabaseEngine.exe) as well as having Office installed corrupts the Jet Driver stack so that SSIS in VS 2008 cannot create the object to read the XLS file. You will see the title error "Unspecified Error" and "80004005" code.

    Resolution:

    1. Uninstall the Jet Engine pack on your development XP machine if you have Office. It will be listed as something like "Microsoft Access Database Engine (2010)".
    2. Run Office 200x setup with the Repair option and reboot.
    3. Try configuring the task in SSIS and it should be able to read the Sheet names again and columns.

     Live Server (32-bit and 64-bit)
    Deploying your SSIS package to a server without Office 200x means it will not have the Jet Engine drivers to read XLS, XLSX files. You must install the 32-bit Office Data Connectivity Components - Jet Drivers mentioned above found here  (http://www.microsoft.com/downloads/details.aspx?familyid=7554f536-8c28-4598-9b72-ef94e038c891&displaylang=en).

    There are no 64-bit drivers; therefore regardless of 32 or 64-bit live environments, this step is the same.
    You should then run the SSIS package as a CmdExec job type using BAT file with something like:

    "C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\DTEXEC.exe" /FILE "D:\SSISDeployment\PbR_ETL\PbR_Parent.dtsx" /CHECKPOINTING OFF  /REPORTING EW  /SET \Package.Variables[User::AdHocRulesetId].Properties[Value];2

    Path C:\Program Files (x86)\ locates the 32-bit mode for SSIS. If you do not do this, the 64-bit environment cannot invoke the Jet Driver (32bit) to read XLSX files.

    Network file locations
    If your Excel file is on a network drive, you must ensure the user that the job runs under can access this. The best way is to change the SQL Server and SQL Server Agent service accounts to a domain account eg. XCLPCT\SQL2008Service. The internet is full of information about this topic but we found it best to use a Domain Account for tons of other benefits too.

    Grant NTFS permissions to this new domain user to the folder(s). Note: It is necessary to change the SQL Server service account itself because SQL Agent uses this account as a proxy to request Active Directory security information - trust me, I had a nightmare just focussing on SQL Agent solely. If you use a Local User for the SQL Server but it is not authorised by AD, you will never get permission to fully run the job properly.

    Furthermore, the Excel Data Source SSIS task will need a full UNC path as it will execute under your new SQL Server Agent service account and might not have the necessary network drive letter mappings. Specify in your configuration file the full UNC path like

    \\mynetworkserver\ShareName\MyNetworkFolder\Data.xls

    Final Notes

    My config that finally worked:

        Local PC:    XP, VS 2008, Office 2007 Enterprise only

        Server:        Win2008, SSIS DTExec 32-bit version by Batch File call, Office 2007 Data Connectivity Components pack, Domain Accounts set for Startup of SQL Server services and NTFS permissions granted.

    Thursday, September 02, 2010 10:28 AM

All replies

  • Thanks so much for this answer
    BI Developer
    Friday, May 27, 2011 4:26 PM
  • Installing the "Office Data Connectivity Components" (download file name AccessDatabaseEngine.exe) as well as having Office installed corrupts the Jet Driver stack so that SSIS in VS 2008 cannot create the object to read the XLS file. You will see the title error "Unspecified Error" and "80004005" code.

     THANK YOU!!!

    Out of the blue, I was finding that our SQL Server 2008 would no longer run a package using the DTEXEC 32-bit, to load an Excel 2007 .xlsx file.

    Your note about corruption made me focus on the installed 'AccessDatabaseEngine.exe' and I noticed that listed underneath it were about 4 Windows updates and a SP1 that were installed a month ago. The job only runs on the 1st of the month, hence me only seeing a problem now.

    The error I got was the 0x80004005 but it seemed to not mention a specific reason at all, other than the 'An OLE DB error has occurred' and the following 0xC020801C. I tried reinstalling the 'AccessDatabaseEngine.exe' but it made no difference, so I uninstalled it from Control Panel (which uninstalled the Windows Updates for me) and then went to install it again - doing this, I got the 'do you want to reinstall or remove it' screen which implied it was still installed, so I chose to uninstall it before doing a fresh install.

    After doing that, it now works again! I am going to make a note that if I Windows Update it again, the server may reinstall those updates that presumably broke it.

    Hope that extra info saves someone else 2 hours.

    Tuesday, April 03, 2012 2:06 PM