Re: Some database discussions...

On Wed, 2017-05-17 at 08:26 -0600, Nathan Andelin wrote:

How did the parent know to chain out to the child on which column to
ensure that there was no match and therefore it would be safe to remove
this parent row?

My problem with DB defined RI constraints is with the generic
non-descriptive error messages, and that the error handling doesn't provide
for cursor positioning and highlighting on relevant columns.

I may be missing something. For shops that implement DB defined RI
constraints, how do they handle user interface requirements (i.e. friendly,
meaningful error messages, cursor positioning on relevant columns, and
highlighting)?

Please note, the following is recalled from memory so its more of an
introduction of ideas than actual instructions - YMMV.

For messages, trapping the error message and then using qmhrcvpm to grab
the error and/or diagnostic then allows a more meaningful qmhsndpm
escape/diag message to be propagated up to the display or when a
meaningful message is not available use (if I recall correctly)
qmhrsnem/qmhmovpm to re-send/move the normal message to the display
message queue. I use that for a few things, such as sending more
understandable record locked messages than the generic one.

I have also seen an article (on iprodev I think) that allowed a way of
sending messages for constraints by naming the constraint in such a way
that it was possible to translate its name into a more human readable
message. Instead of the generic "CPFxxxx constraint error for constraint
&1" the program retrieved the constraint name (from &1) CST0004,
CST0009, etc. from within the error message and then used that name to
send the actual message "CST0004" from a message file that said
something along the lines of "invalid customer prefix error".

Depending on what information is supplied within the system supplied
error message, message data, for the RI constraints it should be
possible to do the same kind of trap error>retrieve message data>send
more human readable message.

The above works well with programs that use sub-procedures as they have
message queues for the procedures... so you can trap and leave the
message (or re-send it as a diag) within the procedure and send a
different message to the "program message queue" that the display
shows... that way if someone goes "why is it saying that X is wrong" you
can check the job log, see the actual (original) message which might be
far more informational from a programmer/support point of view.

Jon