RE: Triggers 101

Or the solution is in how the program is written.  
1. If you were to update OESECTP before updating OETITLP, it would settle its 
self. 
2. Committment control. 

One of the biggest problems I have seen with using triggers is the philosophy 
behind the original program.
Order entry is always one of the biggest areas this occurs.  A single record is 
not an order.  Its a collection of records, so the routines need to take that 
into account. Using committment control and "finalizing" the updates to the 
database when all records have been updated is a better solution.  This would 
keep the trigger from activating until the Commit. 

Besides, if someone were to exit the session or turn off the workstation in the 
middle of the update you have a problem with not all records being written or 
updated when you are not using committment control.  

IMHO, 

Sharon


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Turnidge, Dave
Sent: Thursday, March 08, 2007 9:15 AM
To: RPG programming on the AS400 / iSeries
Subject: Triggers 101


I am attempting to get our triggers under control and have run into what
I *think* is a problem. It has to do with record locks, and the
discussion we had recently which also included a record lock discussion,
didn't seem to answer my question.

We have an order entry program that updates/adds to file OETITLP. This
program ALSO updates a file OESECTP. OETITLP has a trigger attached that
ALSO updates OESECTP. I believe this is causing a lock issue when the
trigger attempts to update the SAME record in OESECTP that is updated by
the program.

It seems to be that a trigger should not be updating a file that is
being updated by a program that triggers the trigger. Or, maybe, the
trigger needs to be smarter and not run when the trigger is triggered by
said program.

Is there a SOP for this?

Thank you,

Dave
642-371-1163