2 Add a Script Task to the contianer, and set the script to fail, Dts.TaskResult = Dts.Results.Failure
3 Set the ForceExecutionResult on the Script to Success.
4 Execute the package.
The container fails, so it detects the Dts.Results.Failure, and ignores ForceExecutionResult. The task itself is Green, so that indicates success. I think this is wrong, as ForceExecutionResult should be observed by both the task and parent container. Not that it should matter, I think, FailParentOnFailure is false. By design? (Sep CTP)
Ok, so there is a simpler issue here. The sequence container takes no notice of the ForceExecutionResult. Try a container with a simple task that always succeeds. Set ForceExecutionResult on the container to Failure, and the container still succeeds (goes green).|||
Containers don't fail because their children fail. Containers fail because one of their settings (MaxErrorCount, FailParentOnFailure, etc) mandates it to fail.
The task isn't raising an error. So MaxErrorCount doesn't take effect. A failed task doesn't fail the parent by default. Neither is FailParentOnFailure set to true.
Here, like the Disable/Enable, is a brute force method of making something happen. You've made the conceptual assumption that because tasks fail when they have errors, if the task is forced to look like it failed, the parent should behave the same as a task that failed because it had errors.
The feature does what it says and no more. It forces the return value to false. Nothing more. It effects only those features that key on the return value. Precedence constraints are effected by the execution result, failing the parent is not. Neither is there an error raised.
If you set fail parent or fail package on failure, it will fail the sequence.
If you return an error from the script task, it will fail the parent if MaxErrors is set to 1.
HTH,
K
BobP - BIM wrote: