none
Script Task cannot execute in 64-bit environment (KB 932556) RRS feed

  • Question

  •  

    Hi there,

     

    I have SQL Server 2005 SE x64 with SP2 running on Windows 2003 Server R2 x64. The server runs on 2 Quad Core Intel Xeon.

     

    When I try to run an SSIS package in debug mode (within Visual Studio) with a Script Task, it will fail with the following error message:

     

    Error: 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.

     

    I have found the KB 932556 that explains the cause to this issue. There was change in the CLR for Microsoft .Net Framework 2.0. I try applying the following fix: SQLServer2005-KB932556-x64-ENU.exe

     

    However, when I run the fix, I get the following error:

     

    This update requires service pack 0. The service pack for product instance MSSQLSERVER is 2. Download the update for service pack 2.

     

    Would anyone have any suggestion on fixing this issue?

     

    I do not experience any of these issues within Windows XP x64 environment.

     

    Thanks,

    Ben

     

    Thursday, March 20, 2008 9:59 PM

Answers

  • Hi Blouie,

     

     I do noticed that I have to modify the script and forced the recompile. if my development environment is 32bit and my production environment is 64bit, would I have to bring the SSIS packages from dev over to prod and manually force a recompile?

    Understanding that you have 2005 SP2, and your package successfully executed the script task on 32 bit environment,when you delploy this package on 64-bit machine, your coded script task already remain compiled and you need not re-edit. Still if you require some changes to be done in the script task after deploying it to 64-bit machine, you can edit the same way as you did in the beginning without any changes in the settings, you will see that the binary code generation succeeds naturally if your code does not have any syntax errors.  

     

    So where does the binary code reside after the recompile? With the SSIS package?

    Yes, Within the Script Task in SSIS Packages.

     

    Thanks

    Subhash Subramanyam

     

    Friday, March 21, 2008 11:05 AM
  •  Duane Douglas wrote:
     blouie wrote:

    Hi jwelch,

     

    You are right. :-) I do noticed that I have to modify the script and forced the recompile.

     

    So where does the binary code reside after the recompile? With the SSIS package?

     

    Also, if my development environment is 32bit and my production environment is 64bit, would I have to bring the SSIS packages from dev over to prod and manually force a recompile?

     

    Thanks,

    Ben



    i'm not sure about this, but i don't think that the compiled code lives with the package.  afaik, the compiled code is generated when the package runs the first time from a specific location.

    my understanding is that a process is spawned when a package is executed.  so, my guess is that the compiled code is called from this process.  certainly,the package execution process must know where this compiled code resides, and this code must be in a location where the process can access it.

     

    This is not correct. The compiled code is stored in the package. If yuo create a simple package with a Scrip task, and look at the "code" view to see what's happening. If you precompile the code, then you can see the binary assembly data in the package; if yuo do not precompile, the binary data is not there.

     

    As I understand it (I do not have time today to look this up, so you should do so before taking my word for it, even though I'm pretty certain that this is the case) the problem with the 64-bit platform is that there is no Visual Studio for Applications (VSA) compiler for 64-bit. Since VSA is what performs the actual compilation, this means that in order to run your packages with Script code on a 64-bit system (and not using the 32-bit DTEXEC) you must precompile because otherwise SSIS has no way to get from the VB.NET source code to the MSIL it needs.

    Friday, March 21, 2008 2:09 PM
    Moderator

All replies

  • SP2 included that fix, which is why you can't install the hotfix.

     

    Try opening the script, changing something (adding a space or a hard return), and saving it. The warning should go away.

     

    Thursday, March 20, 2008 10:04 PM
    Moderator
  • Hi jwelch,

     

    My SQL Server 2005 SE x64 currently has the SP2.

     

    The odd thing is that if I drag a new Script Task onto my package, it does not have any error. The default value for the attribute PreCompile is TRUE. I could open the task script and modify the script and save it. Still no error. I could run the script in debug mode and still no error. If I modify the PreCompile value to FALSE and then back to TRUE, it will then have an ERROR for the task script. Very odd.

     

    Any thoughts?

     

    Thanks,

    Ben

     

     

    Thursday, March 20, 2008 10:18 PM
  • Did you try updating the script (which forces it to recompile)?

    Thursday, March 20, 2008 10:24 PM
    Moderator
  • Hi jwelch,

     

    I did update the script. There was no problem running it, until I change the PreCompile attribute to False and then back to TRUE.

     

    Thanks,

    Ben

    Friday, March 21, 2008 12:06 AM
  •  blouie wrote:

    Hi jwelch,

     

    I did update the script. There was no problem running it, until I change the PreCompile attribute to False and then back to TRUE.

     

    Thanks,

    Ben

     

    So don't do that Smile

     

    When you flip the PreCompile attribute to False, it removes the precompiled binary code. When you change it back to True, it doesn't recompile the code until you actually change it.

     

    Friday, March 21, 2008 12:16 AM
    Moderator
  • Hi jwelch,

     

    You are right. :-) I do noticed that I have to modify the script and forced the recompile.

     

    So where does the binary code reside after the recompile? With the SSIS package?

     

    Also, if my development environment is 32bit and my production environment is 64bit, would I have to bring the SSIS packages from dev over to prod and manually force a recompile?

     

    Thanks,

    Ben

    Friday, March 21, 2008 12:56 AM
  •  blouie wrote:

    Hi jwelch,

     

    You are right. :-) I do noticed that I have to modify the script and forced the recompile.

     

    So where does the binary code reside after the recompile? With the SSIS package?

     

    Also, if my development environment is 32bit and my production environment is 64bit, would I have to bring the SSIS packages from dev over to prod and manually force a recompile?

     

    Thanks,

    Ben



    i'm not sure about this, but i don't think that the compiled code lives with the package.  afaik, the compiled code is generated when the package runs the first time from a specific location.

    my understanding is that a process is spawned when a package is executed.  so, my guess is that the compiled code is called from this process.  certainly,the package execution process must know where this compiled code resides, and this code must be in a location where the process can access it.
    Friday, March 21, 2008 8:45 AM
    Moderator
  • Hi Blouie,

     

     I do noticed that I have to modify the script and forced the recompile. if my development environment is 32bit and my production environment is 64bit, would I have to bring the SSIS packages from dev over to prod and manually force a recompile?

    Understanding that you have 2005 SP2, and your package successfully executed the script task on 32 bit environment,when you delploy this package on 64-bit machine, your coded script task already remain compiled and you need not re-edit. Still if you require some changes to be done in the script task after deploying it to 64-bit machine, you can edit the same way as you did in the beginning without any changes in the settings, you will see that the binary code generation succeeds naturally if your code does not have any syntax errors.  

     

    So where does the binary code reside after the recompile? With the SSIS package?

    Yes, Within the Script Task in SSIS Packages.

     

    Thanks

    Subhash Subramanyam

     

    Friday, March 21, 2008 11:05 AM
  •  Duane Douglas wrote:
     blouie wrote:

    Hi jwelch,

     

    You are right. :-) I do noticed that I have to modify the script and forced the recompile.

     

    So where does the binary code reside after the recompile? With the SSIS package?

     

    Also, if my development environment is 32bit and my production environment is 64bit, would I have to bring the SSIS packages from dev over to prod and manually force a recompile?

     

    Thanks,

    Ben



    i'm not sure about this, but i don't think that the compiled code lives with the package.  afaik, the compiled code is generated when the package runs the first time from a specific location.

    my understanding is that a process is spawned when a package is executed.  so, my guess is that the compiled code is called from this process.  certainly,the package execution process must know where this compiled code resides, and this code must be in a location where the process can access it.

     

    This is not correct. The compiled code is stored in the package. If yuo create a simple package with a Scrip task, and look at the "code" view to see what's happening. If you precompile the code, then you can see the binary assembly data in the package; if yuo do not precompile, the binary data is not there.

     

    As I understand it (I do not have time today to look this up, so you should do so before taking my word for it, even though I'm pretty certain that this is the case) the problem with the 64-bit platform is that there is no Visual Studio for Applications (VSA) compiler for 64-bit. Since VSA is what performs the actual compilation, this means that in order to run your packages with Script code on a 64-bit system (and not using the 32-bit DTEXEC) you must precompile because otherwise SSIS has no way to get from the VB.NET source code to the MSIL it needs.

    Friday, March 21, 2008 2:09 PM
    Moderator
  • Thank you all for answering my questions.

     

    SP2 does fix the issue with the execution of the SSIS packages within a 64-bit environment.

     

    My issue here was my ignorance on how to force the script to re-compile.

     

    As for the different 32bit dev and 64bit prod environment, I have found that I could precompile the scripts on my 32bit dev and then load the SSIS pakcage onto my 64bit prod and it will run fine. In another word, it looks like the 64bit environment have no problems with running 32bit script binary.

     

    Why is this possible? Is it because scipt binary are portable and can be executed in either 32bit or 64bit environment?

     

    Thanks,

    Ben

    Monday, March 24, 2008 2:02 PM
  • Assuming you don't reference a 32-bit only or a 64-bit only assembly from your script, then yes, the binaries are portable.
    Monday, March 24, 2008 3:23 PM
    Moderator
  •  

    hi,

    is there any solution i can set precomile property to true  for multiple packages from command line

     

    Thanks

    Tuesday, October 14, 2008 3:07 PM
  • I have Server 2008 x64 and some hotfixes out there for Script tasks to allow debugger to step in, or even set variables, does not seem to exist. I tried to download a Vista version of x64 for the exact error I was getting, but will not install on Server 2008. I will have to see if I can recreate the issue, but ended up going back to a machine running server 2003 32 bit to get past it. It runs fine on x64 as a schedule package though.

    Friday, September 4, 2009 8:02 PM