RE: triggers within commit cycles

Hi Bruce!

I've used triggers, and I've used commitment control, but not on the same
files.  With that in mind,

>When the trigger fires is not the question.

It is if you take the newbie's point of view!  Let's say the application is
order entry.  There's a trigger on the detail records that accumulates total
purchases for a customer, and updates a "credit extended" file.  We start a
commit cycle and write the detail records one by one as they're entered.  We
get to the end and the user aborts because they don't want to give out their
credit card number.  The detail records are written but not committed,
there's no header record yet, and we do a ROLLBACK.  Did triggers on the
detail records ever fire?

>Why would a rollback fire an "opposite" trigger and where does
>THAT trigger come from? What is the opposite of an update trigger?

Yeah, sorry.  Quick typing, slow thinking.  What I was thinking was that if
the records were added, the rollback would do an implied delete, thus firing
the delete trigger.  As for the opposite of update, I was thinking that the
old and new copies would be reversed in the trigger buffer.  Again, a
newbie's perspective.

>If you are doing IO in the trigger, you must decide whether
>or not to include the IO in the commitment cycle or separate
>from that commit cycle. If you separate it, the IO will be
>there after the rollback operation. It's no different than
>calling a program.

That makes plenty of sense.

>Rollback operations, while they are IO in nature are
>different than standard IO operations.

I am seeing that.  Man, I need to set up some demos so I can get a Very Good
handle on the ramifications.

>Would you want a delete cascade to happen just
>because you chose not to insert a record into the database?

No; especially if I had 10 records already there and this commit cycle added
5 more.  What a mind-bender!  Basically, I should very strongly consider
putting all the trigger I/O in the commit cycle, which would probably be the
simplest way to handle things.  if ALL the I/O is in the commit cycle, it
all gets committed/rolled back together.

Great post Bruce, and Great Question Charly!  I love this list :-)