Metadata Issues

I am experiencing something really bazaar. The package I created usign SQL2K5 Sept. CTP Builds and functions just fine in one domain. When I deployed to another machine & new domain, we get Metadata errors within dataflow that was modified. We had encountered this earlier but by rebuilding the package it has solved the problem. This time, rebuild is not helping. How can metadata for data flow of a package get corrupted from one environment to another. Also, what's the purpose of building a package when the package is in XML (Text). I don't see any binary code for script tasks.

What exactly is the message? My favourite at present when moving between environments is the encyrption error for passwords (or any sensitive propertry), since the default protection uses the user key, so obviously changing domains changes accounts and therefore the decyption fails. Setting don't save sensitive information and use configurations to apply passwords again helps somewhat.|||Thanks for your reply Darren. I have already cross the hurdle of Package Protection level issue. Current settings are "Don't save sensitive" info. I am curious to see if they modify this default setting in RTM rel.
|||Using the RTM release now available to MSDN subscribers, the default is User Key still.|||Great!!. By the way, what does a Build functionality do for a package when script tasks within either control flow or data flow are set not to compile on save. If I don't build the package, it still works so why build it?
|||

Scripts can be compiled or not. If compiled then they run faster since there is no compilation overhead each time the package is run. I wasn't aware that this was linked to the package build, I assumed it happened within the script editor itself and VSA. Only downside of pre-compiled scripts is they are processor specific, so x86 to x64 deployments for example will fail.

|||You'd be better of ignoring me and just reading Books Online. The package Save induces the compilation.

From ScriptTask.PreCompile

Property Value

true if the VSA script is compiled when the package is saved; otherwise, false. The default value is true.

Remarks

VSA scripts must be compiled before the package runs. The Script task includes the option to pre-compile script into binary code when the package is saved. When script is precompiled, the language engine is not loaded at run time and the package runs more quickly; however, compiled binary files consume significant disk space. Script that is not precompiled is compiled at run time, which slows package execution but consumes less disk space. When storing large packages is not a problem, you should pre-compile your VSA scripts.

|||

DarrenSQLIS wrote:

Only downside of pre-compiled scripts is they are processor specific, so x86 to x64 deployments for example will fail.

Not really. The script is precompiled to MSIL (.NET intemediary language) which is platform-independent. It will be JIT-ed to process-specific code at runtime.