Re: Default user ID in SQL table - trigger

rob@xxxxxxxxx wrote:

Then again, on some operations you may NOT want to use a
mediator, unless I don't understand the program stack well. For
instance, pretend you're using some silly application that
insists on multi member files. And since you are using multi
member files you can't use referential or check constraints. So
you decide to duplicate that with a trigger. Now, your trigger
can chain out to the 'parent' file and say you can't add this row
to the 'child' file because the parent doesn't exist. And since
your trigger can be called from any file operation (ie your
application, UPDDTA, Excel, File transfer, etc.) the way to
handle that might be to send an escape message.

The stack below & above the database code, that which triggered the event and that which handled it, is not really relevant to preventing the triggered I/O event from being completed by the database.

An escape message needs to be signaled to the QDB* program that performs the specific I/O, irrespective of what is in the stack between the DB I/O and the procedure or program that decided to block\terminate the current I/O request. In response, the database signals a common error to whatever code attempted the I/O; i.e. an error "I/O failed due to trigger" is sent by the database to whatever application made the I/O request. With a named arbiter [the mediator], then such a message could be sent to the mediator program instead, or the design could instead be by return code to the mediator, and then the arbiter would encapsulate the code to [re]signal the escape message to the correct database I/O program. More valuable\important for OPM and for a return code driven versus messaging driven design for the trigger program.

FWiW the specific escape message that is sent to the database is irretrievable, so a diagnostic is probably valuable to be logged in addition, to inform why the I/O is being blocked:
http://archive.midrange.com/midrange-l/200809/msg00208.html

Regards, Chuck