November 12, 2013 at 3:33 pm
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 (http://go.microsoft.com/fwlink/?LinkId=81885).
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.
November 13, 2013 at 2:01 am
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.)
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
November 13, 2013 at 12:41 pm
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:
http://www.sqlservercentral.com/Forums/Topic617157-148-1.aspx
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply