RE: Use of Triggers in RPG

Be careful with this approach if you use commitment control. I've been using
the DTAQ method for asynchronous trigger execution for a number of years,
and have been bit by this combination, hard.

Essentially, when you're running under commitment control, the trigger
program will be called by the DB as soon as you perform the insert -- before
you actually commit. Your trigger logic is executing based upon an
uncommited DB change. If your trigger program were running under the same
commitment control boundary, this would not necessarily be a problem.
However, since your trigger logic is now in another job altogether, it is
being executed regardless of whether you commit or rollback.

Moreover, if you do choose to rollback, the DB does not fire a corresponding
*DELETE trigger, so it's not easy to even reverse any changes made by the
*INSERT trigger.

Ideally, *AFTER triggers should not be fired by the DB until it's received a
commit. However, that may very well create it's own set of challenges which
I haven't taken the time to consider.

Regards,

John Taylor
 

> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx 
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Alan Campin
> Sent: Tuesday, July 26, 2005 12:56 PM

> The best way I think is to use a data queue and have a data 
> queue server. Each time a call is made to the trigger, write 
> to data queue. This works well because you don't need real 
> time updates and no overhead in the trigger program.