Re: Trigger techniques

In our stuff we had to deal with this by creating a service program that
wraps all updates, inserts and deletes so that when the call was made
recursively we know to return.

TRGF_SetRecursion();
Exec Sql Update TRIP_NOTE
Set UPDATED_TIMESTAMP = CURRENT TIMESTAMP,
UPDATED_USER_ID = :UEngNoteBFields.UserId
:UEngNoteBFields.UseridNullInd,

OBJECT_VERSION = :UpdateObjectVersion + 1,
NOTE = :AddInfo
Where Current Of NoteB1;
TRGF_ResetRecursion();

And in the called service program.

If TRGF_IsRecursiveCall();
Return;
EndIf;


On Thu, Apr 8, 2010 at 10:46 AM, James H. H. Lampert <
jamesl@xxxxxxxxxxxxxxxxx> wrote:

Charles Wilt wrote:

The only possible issue with this...

If your actual trigger does an update to another file that also has
the gentrigger attached, the process will blow up because RPG doesn't
allow recursive programs.

Or, as happens in my Workflow trigger, you simply catch the recursion
exception and ignore it: while we made Workflow a trigger, so that the
scripts will trip regardless of whether the file modification is done
from our application, we also designated it a "well-known limitation"
that changes made by Workflow scripts don't trip other Workflow scripts.

If you allow recursive calls to a script-driven trigger, it would be far
too easy to go into not just an ordinary infinite loop, but an infinite
recursion. That would be bad. That would be "don't cross the streams" bad.

--
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.