John, I to have lots of triggers Only time I need to suppress a trigger is when I update say a MbrCurHomeAdr table I certain columns have changed I insert a record into MbrPrvHomeAdr. Well I can also insert a record directly into MbrPrvHomeAdr. the MbrPrvHomeAdr trigger has and update of record count in the MbrMasterTable. I also update that count in the Update trigger for the MbrCurHomeAdr. To prevent a duplicate update of the count I set a global variable in the MbrCurHomeAdr trigger that caused a bypass in the MbrPrvHomeAdr trigger.
Not the best coding but I needed to get it working. Probably should do the update only in the MbrPrvHomeAdr Insert trigger. I resorted to this because BEFORE INSERT and BEFORE UPDATE triggers WHERE CURRENT OF SYS_NEW cursors are read only. I had to move some of my planned audit logic from the subsidiary table into the master table. Didn't have time to rethink whole audit scheme when I discovered that fact. Almost all of my triggers are BEFORE INSERT/UPDATE/DELETE triggers. Are you by any chance attempting your actions in an AFTER INSERT/UPDATE/DELETE trigger? I was having problems with WHERE CURRENT OF SYS_OLD cursor in the AFTER trigger. I don't know whether is was a problem with my select statements (very complex) or with availability of that syntax in the AFTER triggers. I didn't have time to experiment as I folishly made a change to the database without checking out the trigger. Long story short, could you set a global variable that you could test in you trigger to ignore updating the audit data. Jim Bentley American Celiac Society [EMAIL PROTECTED] tel: 1-504-737-3293 --- On Wed, 8/13/08, John Engwer <[EMAIL PROTECTED]> wrote: > From: John Engwer <[EMAIL PROTECTED]> > Subject: [RBASE-L] - Triggers > To: "RBASE-L Mailing List" <[email protected]> > Date: Wednesday, August 13, 2008, 2:57 PM > I use a lot of triggers in my applications and sometimes I > would like to > suppress the trigger for certain processes. Such as the > audit trigger when > updating a large table. Because I usually perform these > procedures at night > when no one else is using the database, I currently drop > the trigger when I > start the routine and then add it back at the end of the > procedure. It > works fine except that the trigger is then not active for > other users that > may log onto the system unexpectedly. > > I think that I may program a switch into the procedure to > bypass the code in > the trigger procedure but I thought that I would ask how > other developers > handle this issue. I tried using the ABORT TRIGGER in the > procedure but it > did not suppress the trigger. > > Any input will be appreciated. > > John
