Always ensure that any file opens in triggers resolve to specific paths
or accounts - that quick and dirty q-pointer from the 'wrong' account
will get you if you don't.
You can't debug through triggers (because they run in a transaction).
We also use a 'sub' trigger system but call @subroutines
Stuart:
Are you saying one should create a single trigger program like...
MASTER.TRIGGER.U
001 SUBROUTINE MASTER.TRIGGER.U (ExecStat, DictFlag, atFILENAME, atID,
atRECORD)
002 COMMON \trFILES\ TABLE.FV
003 IF FILEINFO(TABLE.FV, 0) = 0 THEN ; ** UD version
004OPEN '', 'TABLE' TO TABLE.FV
Hi Bill
That's pretty much what I do, except each file has a list of small
subtriggers. That way, if we need to add another action (e.g. another
secondary update) or to temporarily suspend an action, they can be added
into or knocked out of the list. The overhead is on calling the master
trigger
Brian:
I have a couple of questions:
1) Does the subroutine called by the master trigger need to be globally
cataloged?
2) Does a CALL @... always reload the routine, as opposed to using a cached
copy,
especially if the subroutine is globally cataloged?
Thanks,
Bill
-Original
