The one line that I removed from my cleaned up version of the trigger code before posting it here was:

PRAGMA AUTONOMOUS_TRANSACTION;

What I did not mention, at least not directly, is that the ERP system already had a before update trigger, an after update trigger, and a row level after update trigger on the OPERATION table. At least in Oracle 10.2.0.x it is not possible to control the order in which the triggers fire (two row level triggers on the same table, for instance) so there is always a chance that the STATUS column might be updated in the other row level after the new trigger fired – and that might cause missing emails. The possibility of potentially lost emails was something that I considered before answering the email request.

Timur, your suggestion reminded me of something that I suggested to the author of the email roughly a year ago (but did not think about until I saw your comment) – the event should be logged to another table, and then a scheduled report of some sort (I was thinking of something not scheduled with DBMS_SCHEDULER, but instead a separate program like my Report Server program) to be run against the other table. I believe at that time I suggested the logging approach based on something that I read that was authored by Tom Kyte. If I recall correctly, he was writing about the reasons why you would not write to an operating system file as a means of logging that an event happened – so that if a deadlock happened after that point the text file was written to, or an automatic transaction rollback and restart was preformed (I believe that Tom mentioned this possibility in his most recent book) the log file did not show that the event was successful when it was not, or show that it was successful twice when in fact it only completed once.

the only way to go is use autonomous_transaction.. But is this a suitable place for autonomous_transaction?