32-bit...64-bit...Excel 2007...Excel 2010...nonetheless a .xlsx File

Question

My head is spinning...soooooo here's the deal...
The client provides us a .xlsx File. Now I have no idea how this is created and saved...via Excel 2007...Excel 2010
When I attempt sourcing the .xlsx File in my SSIS Package I get the error "External Table is not in the expected format"
Sooooo, I figure I'd write a C# Edit Script to read .xlsx File and Save it as a .xls file using the following syntax...
string StrFileName = (Dts.Variables["User::FileName"].Value.ToString());
StrFileName = Path.GetFileNameWithoutExtension(StrFileName);
string StringSourceFile = (Dts.Variables["User::FilePath"].Value.ToString()) + StrFileName + ".xlsx";
string StringDestinationFile = (Dts.Variables["User::FilePath"].Value.ToString()) + StrFileName + ".xls";
// This initiates the Excel Application
Microsoft.Office.Interop.Excel.Application excelApplication = new Microsoft.Office.Interop.Excel.Application();
// This Opens the Source .xlsx File from Emdeon ePaySmart
Workbook workbook = excelApplication.Workbooks.Open(StringSourceFile, XlUpdateLinks.xlUpdateLinksNever, true, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing);
// This will Save the Source .xlsx Emdeon ePaySmart File as a .xls File...note xlFileFormat.xlExcel5
workbook.SaveAs(StringDestinationFile, XlFileFormat.xlExcel8, Type.Missing, Type.Missing, Type.Missing, Type.Missing, XlSaveAsAccessMode.xlExclusive, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing);
// This will Close the Source
workbook.Close(false, Type.Missing, Type.Missing);
// This shuts down the Excel Application
excelApplication.Quit();
Note xlFileFormat.xlExcel8
Now this worked PERFECTLY client side. Then when I created a SQL Server Agent Job it blew up and from what I read the SQL Server Agent Job does not like running dynamic Excel commands.
Soooooooo now I'm back at the drawing board and figured I'd use OLE DB to source the file.
I am using this Connection String for the .xlsx File
string StringConnection = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + sourceFile + ";Extended Properties=\"Excel 8.0;HDR=Yes;IMEX=1\"";
Now I understand that the OLEDB.4.0 Connection string is incorrect for a .xlsx File. (Which is why I probably tried to do this with dynamic Excel commands to begin with)
Now comes the chicken and the egg problem...
If instead I try using the OLEDB.12.0 Connection String it tells me it isn't installed
My network, copied Microsoft Office 2010 installed is 32-bit
So if I try to install the 64-bit Microsoft Access Database Engine 2010 it tells me I have to Uninstall Microsoft Office 2010. Well that is not possible
So my question is this...How in God's name can I try and process this .xlsx File??? I am at a complete loss here.
I did come upon this Posting previously...in italics below but it fell short in terms of providing a solution.
Can anyone please help me out here?
Thanks in advance for your review and am hopeful for a reply.
ITBobbyP85
When I create my connection manager to connect to a .xlsx file, I get the error message that says:
"Test connection failed because of an error in initializing provider. External table is not in the expected format."
The provider selected was the ole db "Microsoft office 12.0 Access Database Engine...", and in the All tab I entered "Excel
12.0" at the top where it says Extended properties.
Here is the stumper:
My import package(s) has (have) been running manually for the last 2-3 weeks, but now i've finished an automated system that downloads
the files from the ftp site, unzips them, validates all the expected files are there, renames and relocates the files to the names/locations expected by my ETL, and then runs the ETL.
I found out today that the people who manually did this process were each time opening the file and then saving it to the correct location
in Excel 2007. 
When I try to run my ETL on the files in the automated process, it fails with the above error. If, however, I just open the file and
save it (also in 2007), it runs fine. I have been trying to figure out what saving the file is doing to change it to be in the expected format.
I have tried to use an excel 2003 connection to connect to a copy of the file with a modified extension of .xls and that didn't work.
(in case it was in another version of excel and someone just changed the ext)
I then tried to access the file with the OLE DB provider, as above, but instead of entering 12.0 on the Extended properties line, entering
9.0 or 14.0 in turn (creating new sources/connections each time), and when I do that, both times I get an error that says: 
“Test connection failed because of an error in initializing provider. Could not find installable ISAM.”
Am I missing something? Is there something else that simply opening and saving the file might be doing to make it paletable to ssis?
If we install excel on the db server I realize i could probably open it up and save it as excel 2007 and that would do the trick, but
the dba is resistant to this idea, so I thought I'd see if anyone has any other ideas?
If we do have to install excel on that server, does the version have to be excel 2007 in order to programmatically save it as type 2007?
thanks in advance for your thoughts on the issue...

Answer 1

You just need to install the latest ACE OLEDB (JET) provider, then when you set the package to run use a proxy with proper rights to access the Excel file on the file system.
http://www.microsoft.com/en-ca/download/details.aspx?id=13255
Arthur
MyBlog
Twitter