Hi. We run a STD2008 64 bit relational engine SP1 in production.
We recently migrated a pkg that reads an xlsx excel file from a separate server and got the following error.
Error: 2013-05-07 13:04:16.65
Source: xxxxxxxx Connection manager "Excel Connection Manager" where xxxxxxxx is the name of a sub package.
Description: SSIS Error Code DTS_E_OLEDB_EXCEL_NOT_SUPPORTED: The Excel Connection Manager is not supported in the 64-bit version of SSIS, as no OLE DB provider is available.
A long time ago when the project started we followed the instructions at this link to install a provider on the target production machine (where the pkg would run) http://www.microsoft.com/en-us/download/details.aspx?id=23734 instead of installing excel there. This was in anticipation of this pkg's needs. I believe the goal was to have a 2007 excel connector for ssis. I believe we forgot to test this plumbing when the project switched hands.
From our network guy's docs, it looks like an app called AccessDatabaseEngine is what got installed as a result and I'll be checking soon with him to learn if it somehow was uninstalled.
I checked the solution and noticed that properties-> debugging->run64bitRunTime has been set to true all along during testing on my 32 bit client machine where excel 2007 is installed. The pkg runs from a command line in production. I have to check if excel 2007 is installed on the server from where I get the excel file. That may be just a file server and I'm not sure if an excel installation (or connector installed there) there makes a difference to ssis or not. I'm suspecting no. That actually opening the excel file in an ssis pkg takes place on the ssis server.
I'll look up the error but am posting here in case the community knows where we went wrong and if we have the option of remaining 64 bit.
I see one workaround at http://sqltechconsulting.com/2010/03/29/error-0xc00f9304-the-excel-connection-manager-is-not-supported-in-the-64-bit-version-of-ssis/ but that worries me considering I want to take full advantage of a 64 bit version . It suggests that the command line point at location “D
rogram Files (x86)Microsoft SQL Server100DTSBinndtexec.exe” /f “D:Test.dtsx” /X86 . I think the author meant . D:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn . I'll try to look up the meaning of the trailing character /X86 but if the community knows whether or not i need it, please let me know. Also, from other posts it appears the debugging 64 bit flag is only relevant in design mode. Also, it appears that the x86 directory does also exist on my target server. Currently my .bat file points at "C:\Program Files\Microsoft SQL Server\100\DTS\Binn\dtexec" which I understand is the 64 bit executable. Also, I read something somewhere that even if you run the 32 bit executable, being on a 64 bit machine can still pose problems. Any straight answers would help.
I do see at http://www.mssqltips.com/sqlservertip/1812/dtexec-command-line-parameters-using-command-files/ that the /x86 param is ignored when run from the command line.