May 22, 2008 at 6:26 am
[font="Arial Narrow"]"are set to correct values after the package has started executing"[/font]
This is not correct. Package configurations are set before validation. Then validation is run, then pre-execute, then execute. You should not have to use DelayValidation to handle package configurations. You should only have to use DelayValidation is you are using expressions, variables, or script tasks to set connection information, or if you are doing something like copying an excel spreadsheet to the location that your excel connection manager is pointing to.
What sp of SSIS are you using?
You can further delay validation using sequence containers, so if you are finding that something is being changed further into your package than setting DelayValidation on the package can handle, throw everything that needs to be delayed into a sequence container and set the DelayValidation on the sequence container to True. This will delay the validation of the conponents within until the execution of the package reaches the sequence container and will actually not validate the components if the package execution never reaches the sequence container (if you had some conditional logic).
May 22, 2008 at 7:03 am
"Package configurations are set before validation. "
I am not here to argue about the exact timings of the Validation -> Package Execution -> Object/Container Pre-Execute Validation -> Execute Object/Container sequence.
It is a matter of fact that the package validation occurs before execution and expressions and the like are set. Therefore, if any non-trival configuration is done that changes values to be correct for the execution environment which would otherwise be invalid then DelayValidation has to be set to TRUE.
The Questions is:
Is there anyone out there that is using Itanium2 Servers (Dual-Core) and seeing a different behaviour for a package execution when compared to x64 Xeon and Single core Itanium2?
I get validation warnings on IA64 (DC) for connections, the same package executes on x64 Xeon with no warnings and it is ETL'ing to the same IA64 (DC) Sql Server engine. Is this a broken IA64 build WRT SSIS, at least in this regard?
Viewing 2 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply