We are running SQL Server 2005 R3 on Windows Server 2008 R2. I created, deployed and installed an SSIS package all in the 64 bit environment. I don't have any script tasks but I have dozens of execute SQL tasks. This thread, http://social.msdn.microsoft.com/Forums/en-US/sqlintegrationservices/thread/6b7d724b-2c5f-4ea9-902b-a83a410ec234/ talks about editing script tasks and recompiling the SSIS package. Since it was originally compiled on a 64 bit server, I'm not sure what that would do. When I run the SSIS Package from SSMS I get precompile warnings but when I run it from SQL Agent I get precompile errors. Is this a differnt bug???

Please try this for SSIS 2005.. http://quest4gen.blogspot.com/2010/03/script-task-recompilation-error.html Let us TRY this | My Blog :: http://quest4gen.blogspot.com/

Like I said, I'm not using any script tasks. I assumeded the error might be from my Execute SQL Tasks. There is no precompiled option for an Execute SQL task. There is a BypassPrepare option, which I have set to True.

Hi John, From your descriptions, I know that the package don't include any script task. However, the error "Precompiled script failed to load" occurred. It is a little odd. Based on my research, the error "Precompiled script failed to load" only happen when the packge is trying to compile the code in a script task or script component, and the PreCompile is true, the PrecompileScriptIntoBinaryCode is false. In this case, could you please check if there is any script component in the Data Flow Task? The Script Component can cause the issue too. Also, could you please try to run the packge in 32 bit mode? In 64-bit mode, scripts must be precompiled, however, in 32-bit mode, the scripts can be compiled just-in-time at run time. Thanks, Jin ChenJin Chen - MSFT

Thanks. But I have never used a script task. I wouldn't even know how to use it. I just thought it might be my execute SQL tasks. I guess I have a real live bug here and should contact Microsoft directly for help. This package is eventually going to be processing several hundred thousand, if not million rows per night. I've already had memory problems which is one of the reasons we moved to 64 bit processors. Is there a switch somewhere to tell the package to run in 32bit mode? I can't change the server.

There is a switch to tell the package to run in 32-bit mode - but it's a manual one. If you're using Agent, you'll need to change the job step from an "Integration Services Package" step to an "Operating System" step. Before you do that, switch to the "command line" tab of the job step, and copy out all the arguments you see there. Switch the job step type. Search for "DTExec.exe" on the server. There should be TWO. One will be located in the "Program Files" folder - that's the 64-bit version you've been using with the IS job step type. The other will be located in the "Program Files (x86)" folder - that's the 32-bit version. If you can't find that, then you didn't install 32-bit components on the server, and you'll have to do that now. In your OS job step, put the fully qualified path to the 32-bit DTExec, then paste the command line arguments. Full details here. Like Jin said, I've only ever seen that error with Scripts. There isn't anything else to "precompile"! Please recheck your package for script components inside the data flow. You can open your DTSX file with notepad, and search for "Script" (case sensitive) to see if you can locate one. Talk to me now on

Put me in the too stupid to live category. I finally found two script tasks that I'd put into the program a couple years ago. They're both in the Event Handlers section - I forgot I'd added OnError & OnPostExecute events right out of Knight's SSIS book. One appears to set a flag on error and the other seems to be there only to have a starting point to roll back the database from a snapshot on failure. I'm not sure if I could use a different tool to set a failure variable but I did set both to Precompile False - and I still get the error. Guess I'll either have to look into the 32bit mode thing or pull out the error code until we upgrade to SQL Server 2008. Right now we're just running them manually from SMS.