RE: triggers within commit cycles

> I suppose.  Don't ask me, I wouldn't use triggers for business rules.  If
I
> can write a trigger program, I can write an external I/O module.  The only
> reason to use triggers for business rules is so that you can have things
> like DFU and SQL updates as part of your production systems.

You could force (sort of) people to use the external I/O module if you
secure the database against updates.  I say "sort of" only because you can't
force end-users to abide by your restrictions (like, they run everybody as
QSECOFR.)  This can be an interesting point if you are selling software.
Triggers suffer the same problem, of course (RMVPFTRG.)

The main difference between triggers and external modules is that you must
publish the interface for external modules so the end-user can have access.
Triggers are essentially invisible to the end-user except for the I/O errors
they throw when the user violates a business rule.

A non-religious opinion,
  Buck