Re: Anyone using Triggers to enforce data validation & business rules?

@Buck, I'm not sure what you mean by the call stack being immutable.
Are you saying that your Triggers are only evoked via RLA via 5250
applications which you control?

I used that rationale myself for a long time. I would just perform
data validation and RI constraints in DB I/O service programs bound to
multiple RPG applications. Why employ Triggers at all if you already
employ MVC design - I thought.

After a long period of time I began to believe that I was holding on
to an unnecessarily narrow computing paradigm. Database utilities have
become so robust that they are replacing legacy database maintenance
applications. Database updates are occurring via QZDASOINIT, QSQSRVR,
and other SQL interfaces. PHP Applications are performing DB I/O via
XMLService, which might alternately be evoked via HTTP CGI or QSQLSVR
interfaces, depending on switch settings.

In that context, it seems to me that the owner of the Trigger wouldn't
know how far up the call stack to send *Escape messages.

For me, the discussion of communicating between Triggers and
Applications via QMHSNDPM and QMHRCVPM message interfaces is losing
value. If a Trigger invalidates a record because the value in the
Email column is blank - the application needs to know the name of the
column that is being rejected in order to position the cursor on that
field and highlight it, etc.

Applications that go through ODBC, JDBC, and similar interfaces very
often display what appears like a core dump when database errors occur
- what a joke.

Placing data validation and RI constraints in modules that are
guaranteed to be evoked by all types of applications makes sense. But
applications need better interfaces than *Escape messages.

Nathan.