Let me repeat: I'm in favour of triggers. I think they're necessary to
keeping a sane database. But I don't find this design easier to
maintain than the clunky RLA design.


Thanks for the feedback. I'd like to better understand your concerns. My
previous comment about improving the readability of code had more to do
with creating source members and modules with clearly delineate a
separation of concerns. Say "module A" handles DB I/O while "module B"
handles data validation and business rules.

The source members are more readable because there is less code to read,
and the separation of concerns is clearly delineated. Edit "module A" if
you need to change DB I/O logic. Edit "module B" if you need to change data
validation and business rules. Or edit both modules by opening them in
side-by-side tabs.

Here is a DB I/O module. It encapsulates CHAIN, WRITE, UPDATE, and DELETE


The DB I/O module traps errors using op code extenders and assists with
percolating errors back to procedures which implement the UI.

Here is the corresponding module for handling data validation and business


Both modules perform cleanly separate roles. The DB Event Handler runs
behind a trigger, checks the validity of field values and returns
appropriately formatted error messages.

Your concerns appear to pertain more to complexities which might arise by
implementing cascading triggers. And how visible (or invisible) that code
might be to application developers.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 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].