Re: Triggers: using the same program for both *BEFORE and *AFTER

[Pete Hall <pbhall@xxxxxxxxxxxxx>]

At 07:47 05/26/2002, Reeve Fritchman wrote:
>Are there any issues with using a single trigger program for both *BEFORE
>and *AFTER event processing (with trigger program logic controlled by the
>value of QDBTT)?  I'm not trying to do anything weird from a timing or logic
>standpoint: I know the program will be invoked twice (causing some
>additional overhead) and I doubt you can count on a record's *AFTER
>transaction immediately following the *BEFORE transaction.

I've never tried that, but I can tell you that triggers always fire
synchronously within the application job. I suspect that's also the i/o
thread, but I don't know that. I have several jobs that fire multiple
triggers during a transaction. An example is *BEFORE triggers that perform
cascading deletes (which can not be specified with a constraint if there's
a trigger involved). The first trigger will delete the dependent rows in
another table, which will cause the trigger on the dependent table to fire
and delete dependent rows in still another table, etc. They always fire in
exactly that order, and they each complete their processing before
returning control to the trigger that caused them to fire. The application
process waits until all are done before continuing with the code following
the i/o.


Pete Hall
pbhall@ameritech.net
http://www.ameritech.net/users/pbhall/index.html