March 9, 2011 at 1:12 pm
I have two custom .net wrappers that would allow us to manage how we process SSIS. One is specifically written to handle 64 bit mode, and the 2nd one is written to handle 32 bit mode.
I have update our existing .net component to reference the following dlls: It used to point to SQL 2005 location.
* C:\Program Files (x86)\Microsoft SQL Server\100\SDK\Assemblies\Microsoft.SQLServer.ManagedDTS.dll
* C:\Program Files (x86)\Microsoft SQL Server\100\SDK\Assemblies\Microsoft.SQLServer.DTSRuntimeWrap.dll
* C:\Program Files (x86)\Microsoft SQL Server\100\SDK\Assemblies\Microsoft.SqlServer.DTSPipelineWrap.dll
I am able to reference, also updated all DTS object to reference SQL 2008. Example: change IDTSComponentMetaData90 to IDTSComponentMetaData100
Everything build without error.
When I execute the 64 bit mode, everything works as expected.
When I execute the 32 bit mode wrapper, I gotthe following errors:
* SSIS Error Code DTS_e_OLDB_EXCEL_NOT_SUPPORTED: The Excel Connection Manager is not supported in the 64 bit version of SSIS, as no OLE DB provider is available.
* SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER... error code 0xC00F9304
My question to the forum is why does the connection manager not recognize 32 bit file?(Excell or Access)
I am running this from a 64 bit server. I am also able to unit test this package by manually executing it using debug mode from this same server. Is there different set of dlls that I need to reference to make it call 32 bit ssis? No, I am not calling DTEXEC.
I hope someone encounter this same issue and would be able to shed some light on this error. Thank you.
--sopheap
This is a cross-post to http://social.msdn.microsoft.com/Forums/en-US/sqlintegrationservices/thread/be6919b6-9573-44c7-bee7-0afd031c7a09
March 9, 2011 at 2:00 pm
It's a problem with drivers for excel.
see this: http://toddmcdermid.blogspot.com/2009/10/quick-reference-ssis-in-32-and-64-bits.html
March 9, 2011 at 2:06 pm
Thank you Julie. I am able to manually run this package on a 64 bit server in debug mode. Todd's blog doesn't describe if there is any behavior difference when calling from a .net code.
--sopheap
March 9, 2011 at 2:14 pm
Sopheap Suy (3/9/2011)
Thank you Julie. I am able to manually run this package on a 64 bit server in debug mode. Todd's blog doesn't describe if there is any behavior difference when calling from a .net code.--sopheap
Manually? Like through BIDS? If yes then you may actually running it in 32-bit mode. Check this out: http://dougbert.com/blogs/dougbert/archive/2009/03/16/debug-your-package-in-32-bit-or-64-bit-mode.aspx
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
March 9, 2011 at 2:18 pm
Todd's blog refers to that fact as well. If you are in BIDS, you are running in 32 bit.
March 9, 2011 at 2:20 pm
Yes, That is how I was able to manually run in 32 bit debug mode using the following method: http://dougbert.com/blogs/dougbert/archive/2009/03/16/debug-your-package-in-32-bit-or-64-bit-mode.aspx
--sopheap
March 10, 2011 at 12:19 pm
I want to let everyone knows that this issue is now fixed. It turns out that when we want to force an application to behave in 32 bit mode, we need to change platform target from 'Any CPU' to 'x86'.
This is a tiny change that made a big impact especially when we are using x64 machines. Thank you everyone from responding to this post.
--sopheap
March 6, 2015 at 10:20 am
Where do you find this in SSIS (Script task) ?
March 10, 2015 at 10:17 am
My note related to "change platform target from 'Any CPU' to 'x86' " was for build when we generate dll to make 3rd party SSIS data flow component. You won't find it as prt of the script task.
--sopheap
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply