RE: SQLRPG error MONMSG possible ?

István,

Guess I should have prefaced that with "IMHO" (In My Humble? Opinion).

Using an error indicator on the WRITE or UPDATE operations shows a lack of
planning; it says to me that the original programmer didn't anticipate ever
having a duplicate key error and, when the error finally reared its ugly
head, the programmer quickly slapped in an error indicator to get the
program running again.  Using a SETLL *EQ before a WRITE or UPDATE with a
minimal amount of comments makes it clear that the programmer expected the
possibility of duplicate keys and took appropriate action to avoid causing
an "error" indicator to be turned on.

Opinions aside, here are a few practical reasons for avoiding using an error
indicator to check for duplicate key errors:
1) There are other errors besides duplicate key errors that can cause  the
WRITE or UPDATE error indicator to be turned on; how, then, will you know
what the exact error is (unless you're monitoring for the error in the
INFDS)?  Of course, if you took the effort to monitor errors in the INFDS,
you probably extended the effort to use a SETLL *EQ to check for the
existence of the record.
2) I never presume that the UNIQUE keyword has been defined for a given
access path.  What if somebody removed the UNIQUE keyword from the file,
either inadvertantly or for good reason unrelated to your reliance of using
that to catch duplicate keys?  IMHO, UNIQUE is a machine-level safeguard to
prevent duplicates that would corrupt the integrity of the data, and it
should never be used as a crutch to support a programming practice for which
a technique exists to test for the existence of the key regardless of
whether UNIQUE is specified.

It is my opinion that every database needs at least one access path with a
unique key.  It may well be that the field that makes the key unique is
nothing more than a sequence number or the RRN.  I'm no expert on database
design (and others are asked to comment on this), but I seem to recall from
long ago that one of C. Date's rules for good design speaks to this.

- Dan Bale

> -----Original Message-----
> From: István Rudas [SMTP:Istvan@Rudas.net]
> Sent: Thursday, April 06, 2000 6:56 PM
> To:   RPG400-L@midrange.com
> Subject:      RE: SQLRPG error MONMSG possible ?
> 
> At 13:01 06.4.2000 -0400, DAN BALE wrote:
> 
> >... ... you will avoid the message that's slowing you down.  However,
> this is
> >considered to be a bad programming practice.  (... ... )
> 
> Dan Bale: please would you express more precisely, WHY this is 'considered
> to be a bad programming practice'?
> 
> Since a lot of years I use this error-indicator, making after the
> WRITE-statement the error-handling: this could be (not often used) just
> writing to an error-protocol file with sendmessage to the operator after
> LR, but most likely (=nearly always) I have the so-called Unique key, when
> making the databasedesign, always added with an additional (internal)
> numeric field as last portion of the whole key: so I add +1 to it when the
> error-indicator was *ON until it is *OFF, this means that the program has
> never to STOP with the "blue screen of death" /cpyr bill g./, and I can
> alarm the operator/user/human at the program end (or other logical
> transaction end) with a message if interactive, or a protocol file or a
> list if it runs batch, where he has to look for this "duplicate key" in
> the
> sense of the application, but not-duplicate for the machine!  
> 
> (Would this be only a theoretical discussion, I would say, yes + guilty, I
> am quite never using a UNIQUE key even if I write it in the DDS; as
> practical application maker I say, that it is unique until the moment when
> something goes wrong and in this moment I leave NOT the responsibility for
> answering to a CPF (C G I R?) to a user who is not a programmer - then
> something has to be wrong with MY data design and its ME who has to react
> with a better design).--- Of course, the question of alarming or not
> depends of the nature of the application, as in many cases it could be
> nonimportant to allow more "unique" records (as you mention, then look
> first for the highest key with Setll and so on), then use an internal
> numeric field, see above.
> 
> If your comment was, to use the error indicator and then NOT doing some
> error handling=doing nothing, then we are meaning the same, this can be
> very stupid and is really not professional.
> 
> Thank you for answering
> István (from Austria)
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---