Up until now I've been content with coding RI constraints in DB I/O modules. For example:
However, this week we've been cleaning up a mess in our database that was caused by our failing to implement an RI constraint in one of our programs. One might ask, where were our QA procedures? While that's a valid concern, the problem could have also been prevented if we added a step to our development process to define RI constraints using DDL or ADDPFCST whenever we add new tables to our database? We're adding new tables every month!
I suppose that one pro for using DB defined constraints is that you use a fairly simple declarative syntax as opposed to program logic. While we generally limit DB inserts and updates to a single RPG I/O module per table, I suppose that another pro for DB defined constraints is that they apply to any other interface that shops may chose to update the DB.
What about other pros and cons?
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
This mailing list archive is Copyright 1997-2013 by MIDRANGE dot 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 here. If you have questions about this, please contact