Re: SQLRPG error MONMSG possible ?

Dan,

Again as so many people have stated before. It is not sufficient to just
code a SETLL and check for an equal condition. If you do this there is a
chance (no matter how small) that someone might create the exact record as
you are while you are between the SETLL and the WRITE statement thereby
causing a duplicate key error. So employing both techniques actually makes
the most robust code.

Then you may want to use ILE condition handlers to have really fine control.
:-)

Sorry for my pontification :-)
Eric

______________________________________________
Eric N. Wilson
President
Doulos Software & Computer Services
2913 N Alder St.
Tacoma WA 98407


----- Original Message -----
From: "Bale, Dan" <DBale@lear.com>
To: <RPG400-L@midrange.com>
Sent: Friday, April 07, 2000 8:01 AM
Subject: 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
> +---

+---
| 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
+---