RE: triggers within commit cycles

>What would be nice is a way to set a flag in a job
>that says "bypass triggers"; if I had that level of
>granularity in my requests, I'd be very happy.

When I write triggers, it's typically to do either a parallel update (i.e.
populate a test system from production by culling records) or some sort of
logging (audit trail of updates.)  The big problem for me is that you need
an exclusive lock on the file to compile the trigger program.  As if I could
ever work for a place where THAT can happen.

The fix for me is a small program that gets installed as the trigger, but
does no trigger work.  All it does is to check to see if the trigger should
be active, and if so, to pass the trigger bugger to the real trigger
processing program.  If the trigger fails, it passes back the return code to
the first program, who sends the escape message.  All driven by database
tables, so one can turn a trigger on or off at will.  one can also recompile
the actual trigger processing program without worrying about locks.