Re: Some database discussions...

On 5/17/2017 6:09 PM, Nathan Andelin wrote:

Buck,

Is this something you actually do, or would like to do in all your DB
maintenance applications? Or is it something that has more loop-holes than
the tax code?

I'm building a proof of concept. The situation here is that I
absolutely cannot turn on RI for existing tables / programs because not
one of the existing RPG programs has a 'check for failure' on the native
I/O. Thus, my interest is only for new tables/programs.

The message that you may find, somewhere in one of your call stack message
queues, may contain something like:

Message ID . . . . . . : CPF502D Severity . . . . . . . : 30
Message type . . . . . : Sender copy
Date sent . . . . . . : 05/17/17 Time sent . . . . . . :
15:54:51

Message . . . . : Referential constraint violation on member CUSMSTF.
Cause . . . . . : The operation being performed on member CUSMSTF file
CUSMSTF in library AMWDB failed. Constraint CUSMSTF_R0 prevents record
number 1 from being inserted or updated in member CUSMSTF of dependent
file
CUSMSTF in library AMWDB because a matching key value was not found in
member REPMSTF of parent file REPMSTF in library AMWDB. If the record
number
is zero, then the error occurred on an insert operation. The constraint
rule
is 2. The constraint rules are:
1 -- *RESTRICT
2 -- *NOACTION

Recovery . . . : Either specify a different file, change the file, or
More...
Reply . . . : C

Yes, that's correct. Note that the constraint name is part of MSGDTA.

If you have programs in your call stack that send diagnostic or other types
of messages to call-stack message queues, how do "applications", know what
they should be looking for?

There are two different issues to hand. The first issue is one of RI
violation and displaying friendly messages. For that, there are a
limited number of diagnostic message IDs that need to be covered. I'm
using SQL rather than native I/O but the same is true for SQLSTATE.

The second issue is one of general error handling. It is my experience
that few RPG programmers write code to detect errors, much less handle
them. By putting message handling code into every program in my proof
of concept, the programs will all have the inbuilt ability to gracefully
handle unexpected errors (such as No authority to object, for example).

If they are able to find what they're looking for, are you suggesting that
they parse it to locate what they are really looking for?

Yes.