I also have an FTP component that receives a file and then needs to send back a handshake file. I tried the same method here, but the event keeps propagating up. I created an event handler for the Send FTP task itself, so that in case the remote FTP server isn't responding, it will error out. The Event Handler code is called and I verified that the value in Propagate is indeed False. And yet the event keeps propagating up and kills the whole package. FailPackageonFailure is set to False, FaileParentonFailure is set to False also.
Any idea what I'm doing wrong? Or is this a bug? Is there a work around?
Any help would be greatly appreciated.
On which eventhandler are you setting System::Propogate=FALSE? The one scoped to the FTP task?
Which container is the other eventhandler scoped to?
If you want your package to continue in the evnt of failure then this is configured within the propreties of the package. it is nothing to do with the configuration of your eventhandlers. I think you will find SSIS to be very robust in this regard when you get it working as you require.
-Jamie
|||
Jamie,
Thanks for the reply. The package has a Main task with a For Each Loop that goes through all files in a directory. It then calls an execute package called ETL-Archive. Within ETL-Archive, it calls execute package ETL. ETL is where the real meat and potatoes is at. This is where the FTP task is. The event handler OnError is scoped to the failing FTP task. This is where I set Propagate=False. However, the event keeps bubbling up to ETL, then to ETL-Archive and then to Main, resulting in complete package failure. Even when I have an OnError event handler at the ETL scope where I again set Propagate = False. I'm not sure I understood your comment about the fact that this is configured within the properties of the package? In this case do you mean ETL or Main? And what should be configured?
Thanks again!
|||Also, the FTP task throws two errors because I deliberately configured it wrongly:
Error: 0xC0029190 at FTP Handshake back, FTP Task: Variable "FTPRemotePathGC" doesn't start with "/".
Error: 0xC0024107 at FTP Handshake back: There were errors during task validation.
Warning: 0x80019002 at ETL: The Execution method succeeded, but the number of errors raised (3) reached the maximum allowed (1); resulting in failure.
This in turn will fail ETL, which will fail ETL-Archive, which will fail Main...
|||Hi Jamie,
I just spent 2.5 hours on the phone with Microsoft support, burning up one of my 4 free support tickets that come with MSDN. They confirmed that it is actually a bug. (So I didn't loose one of my 4 support tickets). Apparently some task containers keep propagating Error events up, even though the Propagate system var is set to False. So... the good thing is I know I'm not loosing my mind. The bad thing is that there is no workaround and no fix planned until Katmay. Apparently this bug was fixed in SQL 2005 Beta 3 and reintroduced later. I just installed Build 2153 (http://support.microsoft.com/?id=918222), and the bug is still there.
I'm not sure where to proceed from here. I have an FTP task that I cannot protect with an event handler, so every time my package has to send a little handshake back and the FTP task fails, my whole package bombs. Again... no clue where to proceed from here. How can I ever release such an non-robust package into production?
|||Do we know if this has actually been submitted as a bug, registered with MS.
I ask because I am seeing the same issue with OnPostExecution EH not just the OnError EH you have described.
I checked on the MS Connect website and searched under the feedback but found no evidence of it ?
P R W.
|||Well, after a lot of back-and-forth, Microsoft decided to update their documentation on BOL to make this a 'documented feature'. It was written off as 'works as designed'.
They did NOT register it as a bug (In the case I described in the thread, not sure about your case).
|||"Works as designed"? Did they give a rationale for that?
-Jamie
|||
Have you found in BOL where it states this ?
To me it's a bug because Propagate False should mean no Event Bubbling for ALL Event Handlers not just a select few.
P R W.
|||This is what I got back from Microsoft on the issue:
Bugs
We have filled 2 documentation bugs on this issue:
Doc: Error in Validate phase of Package Task Bubbles up to Next level event handler even if Propagate variable Set to False.
Doc: Propagate Property Set to False in Child Package Task Does Not Prevent Errors from bubbling up to Parent Package OnError event handler
|||Jamie,
There were two issues
1) Event happened locally during validate phase
==> According to MS, the Propagate functionality works during the execution phase, not necessarily during the validate phase. Therefore, any errors encountered during the validate phase will still bubble up.
2) When a local event happens in a child package, the event will automatically jump into the calling (Execute Task) package of the parent. The Propagate functionality is completely ignored here. Not sure about the rationale.
|||Dirk DC wrote:
Jamie,
There were two issues
1) Event happened locally during validate phase
==> According to MS, the Propagate functionality works during the execution phase, not necessarily during the validate phase. Therefore, any errors encountered during the validate phase will still bubble up.
yeah I'm not surprised about that one. I can kind of understand why that is "as designed". It one of those where its as easy to argue for as it is against.
2) When a local event happens in a child package, the event will automatically jump into the calling (Execute Task) package of the parent. The Propagate functionality is completely ignored here. Not sure about the rationale.
So Propogate=FALSE doesn't stop events propogating to a parent package? Hmmm...not quite sure about that one. I don't know why it would be designed that way.
I'll have to check it out.
-Jamie
|||Have you tried setting DelayValidation=true on both the package(s), and DelayValiation=true on the FTP task as well?
I know this approach seems counter intuitive (setting DelayValidation more than once). However, DelayValidation at the container level appears to
have cascading run-time effects, and not cascading design time effects.
DelayValidation at the task level appears to have both design-time and
run-time effects.|||Not sure I've tried that. What are the run-time effects of DelayValidation?|||
The run-time effects of DelayValidation="true" are two fold, that I've observed.
1. When set, task validation is invoked 1 time, that's it. The validation occurs after the task's OnPreExecuteEvent has fired, no less.
Of course, if the task is in a loop container, validation is called one time per loop iteration. Conversely, when DelayValidation is false, validation will be invoked upfront (I've seen it called three times for a given task).
2. Cascading effect. DelayValidation cascades from container to contained tasks.
The "exception" to the delay cascade is that when Delay Validation is set to true on an Execute Package Task, that setting has no effect on the number of times Validation is called on the task in the child package. I say "exception", because actually, Execute Package Task is not a container (does not implement IDTSSequence, more precisely).
No comments:
Post a Comment