Re: Some database discussions...

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;