Re: Avoiding redundant triggers?

[Luis Rodriguez <luisro58@xxxxxxxxx>]

James,

IIRC, triggers are run in the order they were created, so I'm not very sure
how to check if one has already been applied. That being said, maybe you
could check if there are any other triggers created for your particular
table, using the SYSTRIGGERS table (PF QADBXTRIGB ) . If any other trigger
active, then you could exit your trigger without executing any more
statements.

Regards,

Luis Rodriguez
IBM Certified Systems Expert — eServer i5 iSeries
--



On Tue, Feb 1, 2011 at 11:50 AM, James H. H. Lampert <
jamesl@xxxxxxxxxxxxxxxxx> wrote:

> Fellow geeks, geekettes, and gurus:
>
> We recently discovered a situation in which data propagation triggers
> were applied to several files *twice,* resulting in the data getting
> propagated *twice.*
>
> Now in this particular case, there are no other triggers on the affected
> files, so it's fairly straightforward to avoid this situation.
>
> But what of the possibility that some other application has a trigger in
> the same slot? Is there a way to prevent redundant triggering, without
> interfering with somebody else's triggers? I know about trigger names,
> but I don't quite understand how they work, and the helptext and error
> messages from my attempts to use them are rather unhelpful.
>
> It was so much easier under the old "one trigger per slot" rule.
>
> --
> JHHL
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.