Click here to monitor SSC
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in
Home       Members    Calendar    Who's On

Add to briefcase

Error with packages in 64-bit environment Expand / Collapse
Posted Tuesday, November 12, 2013 3:33 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Monday, November 28, 2016 1:42 PM
Points: 850, Visits: 1,785
Version information on my computer :

Visual Studio 2005 Professional, Version 8.0.50727.42 (RTM.050727-4200)
.NET Framework 2.0.50727 SP2
Integration Services Version 9.00.2047.00

SQL Server version information :

SQL Server 2005 Standard Edition (64-bit), Version 9.00.5000.00 SP4

This is an issue I've researched all over the place, but I just can't seem to find a solution. We recently migrated the database server from a Windows Server 2003 environment to a Windows Server 2008 R2 environment. In the process, we changed from running SQL Server 2005 32-bit to SQL Server 2005 64-bit. Now, for our Integration Services packages, essentially, the script tasks do not work.

When executing under identical settings to before, the error message supplied is a rather verbose:

Description: The task cannot execute in 64-bit environment because the script is not pre-compiled. Please turn on the option to pre-compile the script in the task editor.

When turning the pre-compile option on, the Visual Studio designer gives the error:

The task is configured to pre-compile the script, but binary code is not found. Please visit the IDE in Script Task Editor by clicking Design Script button to cause binary code to be generated.

Attempting to enter into the design script and rebuild, make changes and rebuild, remove the End Class and re-add it all while rebuilding, continue to give the same error. If I ignore the error and execute the script anyway, I get the following:

Script could not be recompiled or run: Retrieving the COM class factory for component with CLSID {A138CF39-2CAE-42C2-ADB3-022658D79F2F} failed due to the following error: 80040154.. For more information, see the Microsoft Knowledge Base article, KB931846 (

The solution in that link is referencing versions of SQL Server SP1 or prior, and the solution is to upgrade to SQL Server SP2. Since I am running SP4, the hotfixes in question are not applicable.

I am really out of ideas at this point. I cannot find a way to get this to work. I really do not want to be forced to re-write the packages without the script task, since that will make things very complicated.

At this stage, the only solution I can think of, is to install a 64-bit version of Visual Studio on the server. Going to attempt that, but it's really not a clean solution, since I don't really want to have to use the server to develop our SSIS packages, seeing as how our desktops are still running 32-bit environments.

Any assistance would be greatly appreciated.
Post #1513648
Posted Wednesday, November 13, 2013 2:01 AM



Group: General Forum Members
Last Login: Yesterday @ 2:02 PM
Points: 7,960, Visits: 19,076
If you run the packages in 32-bit mode, does that work?

How did you perform the migration of the packages? Have you tried redeploying them manually? (I'm sure you have.)

Help us to help you. For better, quicker and more-focused answers to your questions, consider following the advice in this link.

When you ask a question (and please do ask a question: "My T-SQL does not work" just doesn't cut it), please provide enough information for us to understand its context.

If your posting includes some T-SQL code, please surround the code with IFCode formatting tags. It helps readability a lot.
Post #1513733
Posted Wednesday, November 13, 2013 12:41 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Monday, November 28, 2016 1:42 PM
Points: 850, Visits: 1,785
Hey Phil,

Thanks for the advice - you definitely started me off on the right track. It was indeed an issue with the 32 bit vs 64 bit environment, but what threw me off was the fact that changing the package configuration didn't solve the problem.

The reason is because, even if the package is configured to use the 32-bit environment, it doesn't actually do that if you run it with dtexec!.

When running dtexec, by default SQL Server uses the 64-bit version!

So the trick is to force SQL Server to run the 32-bit version of dtexec, then all the problems are solved!

See this thread for more information:
Post #1514037
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse