none
Understanding MaximumErrorCount & FailPackageOnFailure/FailParentOnFailure

    Pergunta

  • I'm trying to understand how MaximumErrorCount works.  I've read various blogs and discussions, but they don't seem to touch on an issue I'm having.

    I have a package that has a foreach container, and in that container, a file system task that copies files.  This task may, on occasion, fail.  When this happens, I want to proceed to a couple "cleanup" tasks.

    So it looks something like this:

    Package
    -- ForEach Container
    -- -- File System Task

    On the File System Task, I have the MaximumErrorCount = 1.  Otherwise the Failure constraint always evaluates to false (success).

    On the ForEach Container task, I have the MaximumErrorCount = 0.  Otherwise, the container fails on completion of the failed copy and cleanup.  This is problem #1.

    On the Package, I have the MaximumErrorCount = 1. Otherwise, I would never know about any other errors.  This is problem #2.

    So first, Problem #1.  While the container properly continues after the failure of the copy, it would improperly SUCCEED if part of the cleanup fails.  Now, I would have thought that this is where the FailParentOnFailure properties would come in handy.  I could leave the MaximumErrorCount = 1 for the container (so that any unhandled errors would get raised), and then set the FailParentOnFailure to false for my File System Task, so that the error is handled by the failure constraint, but does not cause the container to fail.  But oh, wait -- it defaults to "False", so this obviously has no impact on that. 

    Next, Problem #2 (which is similar to Problem #1, just at the package level instead of container level).  Since I have my MaximumErrorCount = 1, the package fails in the event of my File System task failing -- even though the ForEach container has MaximumErrorCount = 0, thus suppressing errors at that level.  This makes no sense to me -- why have my container suppress errors, just to have the package ultimately fail.  It seems like my only option here, regarding these settings, would be to set MaximumErrorCount = 0 at the package level, but then this would allow everything to fail, which is certainly not the desired result.

    So here are my questions:

    A) What is this property FailParentOnFailure/FailPackageOnFailure for, then, if not to suppress causing the parent/package to fail on failure a given child task/container?

    B) If setting MaximumErrorCount = 0 on the container/package results in allowing any errors, how can I limit my expected errors to one task so that the other tasks in the container raise errors on failure?

    C) If the FailPackageOnFailure & FailParentOnFailure always default to "False", what is their purpose in life?  It would seem that this would result in every package NEVER failing -- EVER -- assuming you left them their default values (which I always have, since they don't seem to work as expected anyway).

    D) Why does suppressing/handling errors on a child not, in turn, suppress errors on the parent container/package?

    And ultimately:

    E) How can I allow my file system task to fail, but allow the package and container to continue and report success, AND also ensure that it DOESN'T allow my other tasks to fail?

    Thanks so much in advance for any light anyone can shed on my obvious confusion of these properties.

    Jerad
    quarta-feira, 1 de abril de 2009 19:41

Respostas

  • A) What is this property FailParentOnFailure/FailPackageOnFailure for, then, if not to suppress causing the parent/package to fail on failure a given child task/container?

    B) If setting MaximumErrorCount = 0 on the container/package results in allowing any errors, how can I limit my expected errors to one task so that the other tasks in the container raise errors on failure?

    C) If the FailPackageOnFailure & FailParentOnFailure always default to "False", what is their purpose in life?  It would seem that this would result in every package NEVER failing -- EVER -- assuming you left them their default values (which I always have, since they don't seem to work as expected anyway).

    D) Why does suppressing/handling errors on a child not, in turn, suppress errors on the parent container/package?

    And ultimately:

    E) How can I allow my file system task to fail, but allow the package and container to continue and report success, AND also ensure that it DOESN'T allow my other tasks to fail?

    Thanks so much in advance for any light anyone can shed on my obvious confusion of these properties.

    Jerad

    A) In my experience, these properties are used primarly for checkpoints. Setting them to True causes a failure to by immediately triggered on the parent or package, depending.

    B) Set the MaximumErrorCount to > 1 or 0 on the task that you want to catch errors on, and 1 on the rest. The other important thing, which is the missing piece for most people in error handling, is that you go into the OnError event handler for the task or container that you are handling the error on, open the Variables window, and set the Propogate system variable to False. Otherwise, the error bubbles up to the next highest object (the container or package) and basically fires again. That means that the package fails regardless of whether you dealt with the error on the task.

    C) Under the default values, they do prevent errors from taking down the package. However, the Propogate behavior basically means that setting them to false has no meaning. Setting them to True, however, bypasses the Propogate setting.

    D) See B above - if you don't set Propogate to false, you aren't preventing the error from bubbling up.

    E) See B :)


    Hope this helps. Until I understood the Propogate behavior, error handling was a major pain. I still have problems with it occasionally, but not as many.
    John Welch | www.mariner-usa.com | www.agilebi.com | ssisUnit.codeplex.com
    • Marcado como Resposta Jerad Rose segunda-feira, 6 de abril de 2009 13:11
    quinta-feira, 2 de abril de 2009 01:13
    Moderador

Todas as Respostas

  • A) What is this property FailParentOnFailure/FailPackageOnFailure for, then, if not to suppress causing the parent/package to fail on failure a given child task/container?

    B) If setting MaximumErrorCount = 0 on the container/package results in allowing any errors, how can I limit my expected errors to one task so that the other tasks in the container raise errors on failure?

    C) If the FailPackageOnFailure & FailParentOnFailure always default to "False", what is their purpose in life?  It would seem that this would result in every package NEVER failing -- EVER -- assuming you left them their default values (which I always have, since they don't seem to work as expected anyway).

    D) Why does suppressing/handling errors on a child not, in turn, suppress errors on the parent container/package?

    And ultimately:

    E) How can I allow my file system task to fail, but allow the package and container to continue and report success, AND also ensure that it DOESN'T allow my other tasks to fail?

    Thanks so much in advance for any light anyone can shed on my obvious confusion of these properties.

    Jerad

    A) In my experience, these properties are used primarly for checkpoints. Setting them to True causes a failure to by immediately triggered on the parent or package, depending.

    B) Set the MaximumErrorCount to > 1 or 0 on the task that you want to catch errors on, and 1 on the rest. The other important thing, which is the missing piece for most people in error handling, is that you go into the OnError event handler for the task or container that you are handling the error on, open the Variables window, and set the Propogate system variable to False. Otherwise, the error bubbles up to the next highest object (the container or package) and basically fires again. That means that the package fails regardless of whether you dealt with the error on the task.

    C) Under the default values, they do prevent errors from taking down the package. However, the Propogate behavior basically means that setting them to false has no meaning. Setting them to True, however, bypasses the Propogate setting.

    D) See B above - if you don't set Propogate to false, you aren't preventing the error from bubbling up.

    E) See B :)


    Hope this helps. Until I understood the Propogate behavior, error handling was a major pain. I still have problems with it occasionally, but not as many.
    John Welch | www.mariner-usa.com | www.agilebi.com | ssisUnit.codeplex.com
    • Marcado como Resposta Jerad Rose segunda-feira, 6 de abril de 2009 13:11
    quinta-feira, 2 de abril de 2009 01:13
    Moderador
  • Thanks, John, for your response.

    I was able to accomplish this by setting the Propagate system variable.  I now remember using this in the past, and tried to find it before, but was looking for a property of the event handler -- did not look for a system variable.  That "property" seems kind of hidden and not very straight forward.

    Thanks again.
    Jerad
    segunda-feira, 6 de abril de 2009 13:13