RE: Checking for dupe key on WRITE

We're talking about different situations which require different processes.

1. Writing records with some sort of counter ID (such as a "shopper ID" for
a web page/cookie). For me, I use a data area to store that value, lock it,
increment, update, write the record. No chance of duplicates since only one
person can update the data area at a time. Probably no reason to chain or
monitor if done right.

2. Database files with unique keys like customer master, order detail, etc.
In these cases you shouldn't get duplicates either because if you're looking
to see if it's a write or update to begin with, which means you'll want to
CHAIN. Again, hopefully something is in place (such as a lockable data area
containing the next customer ID, or locking an order so more than one person
can't get into it).

3. A "log" type file in which there really is no unique key, and we will
never write duplicate records. Most likely keyed (but not uniquely) by time
stamp.

Sure, there are probably obscure circumstances that I am missing, but this
sounds like #1, and using a different method there should be no instance of
duplicate ID numbers. Done with a monitor, you'd need a loop that iterates
until there is no duplicate key error, incrementing the counter each time.

Ways to skin a cat... countless.. lol

Bradley V. Stone
BVSTools - www.bvstools.com
eRPG SDK - www.erpgsdk.com

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of rob@xxxxxxxxx
Sent: Thursday, January 10, 2008 2:27 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: Checking for dupe key on WRITE


Hear! Hear! Chuck!
It's easy to do a CHAIN, it failed, so I do a WRITE and find out that
someone else did in between and your write still fails due to a duplicate
key. If you did, as Chuck says, and start out with "recover on error"
thinking you have this covered. However if you are under the impression
that your chain covered the solution then you're in for the phone call
situation that Brad described.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





CRPence <crp@xxxxxxxxxxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
01/09/2008 08:23 PM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
rpg400-l@xxxxxxxxxxxx
cc

Subject
Re: Checking for dupe key on WRITE






For those familiar with /presumed fail/ versus /presumed success/ as
methodologies and/or dealing with highly concurrent database
applications, pre-check versus recover-on-error is given significant
design consideration.

FWiW: Having started with the recover-on-error thinking, that code
path is already covered. Having started the other way, the
recover-on-error code is all too often omitted as an oversight.

I dread dealing with those who coded with the presumed-fail but
failed to also code to recover-on-error, and /the error/ is sent by /my
code/. The attitude often expressed... "It worked without error
forever, and now it is failing with 'already exists' errors". Either
they had always had concurrency established, but the system was for
whatever reason not fast enough [method of submit, number of
invocations, CPU speed, etc.] to exhibit the flaw in coding, or they
only just started running the application concurrently. Just because
/my code/ says /already exists/ does not make it a problem in my
code.... But alas, it is easier to claim the error can not be in /their
code/ because it has always worked without error. Ughhh! It must have
been several hundreds of times I had to explain _that_, as the hardware
has gotten significantly faster or when customers finally move off of
their ten plus years old hardware.

Regards, Chuck
--
All comments provided "as is" with no warranties of any kind
whatsoever and may not represent positions, strategies, nor views of my
employer

Bradley V. Stone wrote:

I totally understand that. My view (and experience) is 99.9999% of the

time

the pre-check is necessary/more important. In fact, I'd do it 100% of

the

time, and use the error catch less often. I really can't remember the

last

time I got a duplicate write error when doing a pre-check. If I did,
though, I'd almost want a hard halt to try and figure out why it

happened.

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.


--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.