That is all correct - for normal error processing. However, when you define an error handler filter for a filter, that overrides the default behavior. Basically, you are telling the system, "don't do it your way, I'll deal with the error the way I want to."
On Tue, Oct 21, 2014 at 9:23 AM, Sahil <[email protected]> wrote: > ** > Thanks for the reply, > > BUt from the doc.. i get page 3159 ARS 8.1 guide for all docs > > Error processing > > The server reacts to error conditions in various ways, depending on what > operation you are running. In general, > errors are handled according to where you are within filter processing > with regard to the database transaction: > If an error is encountered during filter processing and the filter has no > error handler, all processing > immediately stops, no further filters or actions run, and an error is > returned back to the caller. > If the error occurs during a Phase 1 or 2 action but before the database > transaction is completed, the > operation is cancelled, the database transaction is rolled back, and no > change is made to the database. > If an error occurs during Phase 3 actions, processing continues, and > changes are not rolled back. However, > if you override filter processing so that your Phase 3 actions are > processed before the database transaction, > errors are handled according to the "before-transaction-commit" rules. The > error handling itself does not > change, but using the override causes actions that are normally deferred > to take place before the database > transaction; therefore, any errors encountered are handled as an error > before the transaction is complete > and terminate the transaction and roll back. > > *To summarize, overriding phasing for a filter moves Phase 3 actions into > Phase 1 actions. Such actions take on the* > *behavior of other Phase 1 actions (that is, if an error occurs while > processing the action, all filter processing is* > *halted, and any database changes are rolled back).* > > On Tue, Oct 21, 2014 at 6:20 PM, Thad Esser <[email protected]> wrote: > >> ** >> Hopefully, this helps: >> >> https://docs.bmc.com/docs/display/public/ars81/Error+processing >> >> "When all the If actions of the error handling filter complete >> successfully, the error is considered handled, the error information and >> keyword is cleared, and the filter in which the error occurred continues >> execution with the next action. If another error occurs during the >> execution of the filter, the error handler is executed again." >> >> So there's no rollback if you have an error handler defined (and it >> executes). >> >> On Tue, Oct 21, 2014 at 8:19 AM, Remedy Support <[email protected] >> > wrote: >> >>> ** >>> Hello friends, >>> >>> I have a call guide filter which is having error handler filter enabled. >>> >>> In the gudie, i have two push fields filters(F1 and F2) which pushes to >>> two forms FM1 and FM2. >>> >>> First push field goes fine, but in the second push filter, i am getting >>> an error. >>> >>> Now, the problem is that the push to form FM1 is not rolling back. It >>> should roll back. >>> >>> I have both the filters with `! sign. >>> >>> I have also tried by putting error handler filter into the Filter 1 and >>> 2, but it did not work. >>> >>> Please suggest, what can be the issue. >>> >>> Thanks a regards >>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> > > > > -- > *Cheers!!* > *Sahil Pathania* > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
