|
>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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.