The AcquireConnection method call to the connection manager "Excel Connection Manager" failed with error code 0xC0202009
I have deployed my packages into Sql Server and I am using Configuration File. Asmy Data Source is Excel, I have changed the connection string during deployment with Server Path. But I am getting the following errors. Actually the File Exist in Path. May I know What is cause of the issue? Do I need to give any permission to execute the package. SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER. The AcquireConnection method call to the connection manager "Excel Connection Manager" failed with error code 0xC0202009. There may be error messages posted before this with more information on why the AcquireConnection method call failed. component "Excel Source Service Contract Upload" (1) failed validation and returned error code 0xC020801C. One or more component failed validation. There were errors during task validation. DTS_E_OLEDBERROR, Error Code: 0x80004005 Source: "MS JET DB Engine" Description : Path is not valid
March 11th, 2008 12:33pm
How are you running the package? Check that the user running the package has access to the specified path...
March 11th, 2008 12:45pm
I am running through Execute Package Utility in SQL Server Management Studio, MSDB Database. Even I have added user to the Directroy where the excel file resides.
March 11th, 2008 1:01pm
Amzu wrote: I am running through Execute Package Utility in SQL Server Management Studio, MSDB Database. Even I have added user to the Directroy where the excel file resides. My SQL Server is 64 bit Windows 2003 Server Xeon Machine. Is it a problem running the package?
March 11th, 2008 2:12pm
In this case, yes it is... Thereis no 64 bit driver for excel. The workaround is to run the package using the 32 bit version of the execution utility. http://technet.microsoft.com/en-us/library/ms141766.aspx http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=167907&SiteID=1
March 11th, 2008 2:17pm
In the Project Properties->Degugging Section, I set Run64bit RunTime to False. It started working now. Thanks for the answers
March 11th, 2008 6:53pm
Thank You So much for this solution
March 13th, 2008 5:49am
Thanks a lot for this solution!! I struggled with this for the last couple of days! Regards
November 4th, 2008 6:28am
Great! Thanks! I had the same problem, and your solution of setting the 64-bit runtime to false is perfect. I was so discouraged last night, spending an hour or two on this. I could get it to export to a text file, but not Excel. Thanks!
December 4th, 2008 11:03pm
Thanks for the answer!:)I was trying to migrate the same package from a 32bit to a 64 bit server and was very puzzled that the SSIS import excel package failed with errors..It was indeed very helpful!!
January 6th, 2009 10:38pm
I noticed too that the Microsoft.JET.OLEDB.4.0 driver will try to read the temp directory underneath the profile of the logged in user. This will cause problems if going through a SQL Agent proxy that does not have permissions to access this folder. If you log onto the box as admin and try to manually start the job from Agent, the job will fail with DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER- even though the same job contains file system tasks that operate correctly on the same file and folder. I ran sysinternals procmon to verify this: procmon shows the file system tasks correctly accessing the same file that the excel driver is pointed to. Procmon also shows an attempt to access the admin's profile temp directory, followed by "Access denied", and quickly followed by a load of an rll file to display the error dts message, and subsequently the threads are terminated and the process ends. Because of this, the process never gets to the point where it is enumerating the ISAM reg keys (HKLM\SOFTWARE\Microsoft\Jet\4.0\Engines), nor does it ever attempt to open msexcl40.dll. This is a bug that needs to be addressed. (win2k3 server - 32 bit) To confirm this, I took the same process and scheduled it under SQL Agent for 1 minute in the future. It worked perfectly.
April 16th, 2009 1:53pm
Hi Rafel, Even i have the same situation, but here i need to run the package using "dtexec" command. do you know how to run the package using dtexec command in this scenario ? Thanks, Rahulrahulv
May 8th, 2009 12:28pm
Thanks a lot It is very helpful for me....
May 12th, 2009 5:01am
Is It possible to call the SSIS package (running 32 bit) from a web application running in 64 bit environment??
June 12th, 2009 4:47am
There are several ways to "trigger" execution of an SSIS package. Here are some: http://code.msdn.microsoft.com/dtexecRemote
June 12th, 2009 11:23am
In the Project Properties->Degugging Section, I set Run64bit RunTime to False. It started working now. Thanks for the answers I know it's too far ago, and I don´t know who you are.. but you saved my life!!!! hehe thanks a lot! =)
October 15th, 2009 1:38pm
Wow, you guys are awesome man. Thank you so much for saving my life. Cheers :)
October 21st, 2010 5:01pm
Thank you! That solved my problem.
October 26th, 2010 5:10pm
Thanks, Rafael. I spent few hours before following your suggestion. Still you saved me few more hours of time. Thanks, once again.
November 1st, 2010 9:47am
@wade_b I had the exact same problem. We run our SQL Agents using a lower level domain account and run our SSIS packages using a Proxy Account. You are correct as Procmon confirmed it for me as well. I gave the Proxy Account rights to the profile's temp directory (C:\Documents and Settings\SQLAgentDomainAccount\Local Settings\Temp) and it worked! Thanks!
November 12th, 2010 11:44am
In the Project Properties->Degugging Section, I set Run64bit RunTime to False. It started working now. Thanks for the answers Great!!! Solved the problem. rbj
December 8th, 2010 2:07pm
Thank you very much this is what I was looking for
October 24th, 2011 6:09am
It works to me. Thank you! :)
September 7th, 2012 11:53am