×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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.
Buck,
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
procedures:
http://code.midrange.com/6c917d5af1.html
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
rules:
http://code.midrange.com/ee85fb606a.html
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.
midrange.com
