We have traditionally implemented data validation, RI constraints, and
business rules in application code. Now, we're moving to what we're calling
"database event handlers", each of which is a service program that pertain
to a single DB table, and exports the following procedures:
on_init() - invoked when the service program is first activated.
on_term() - invoked when the service program is deactivated, or after a
period of inactivity.
on_read() - invoked before or after a "read" event.
on_write() - invoked before or after a "write" event.
on_update() - invoked before or after a "update" event.
on_delete() - invoked before or after a "delete" event.
Database event handlers are loaded in response to database triggers, which
apply to any and all applications. Following is an example:
https://rd.radile.com/rdweb/temp/cusmst_b.txt
The interface provides a procedure for adding response messages to an array
which is shared with applications that invoke DB operations:
dbeMsgAdd();
This procedure has optional parameters for column name and a reference to
additional help text.
Friendly message text is retrieved from a database file via:
msgGetText();
Some of our code may look unfamiliar, as we are using RPG wrappers around
IBM i database functions found in service program QC2IO, as an alternative
to RPG DB I/O op codes. For example:
rlaOpen(); // opens a database file.
rlaClose(); // closes a database file.
rlaPos(); // returns a boolean value, indicating whether a record exists
in a table.
rla is a prefix for record-level-access.
Applications may employ logic such as:
if rlaUpdate();
exsr return_success;
else;
exsr return_errors; // process error array.
endif;
midrange.com
