RE: Embedded SQL, first steps

 <snip>One of the falsehoods of doing all data integrity via programming
and not 
letting the database do any of the work.</snip>

If the programming is correct..it's no problem.  Personally I try to
pull external data into a temporary file & program to update the master
files.  That way I can see the garbage or duplicates without screwing up
my data...(constraints can't do that..)  Constraints CAN prevent the
data from getting hosed (if done right) but I've seen too many times
where constraints get into a check pending state, etc. and no one does
due diligence to clean up the stuff...I'll stick to programming.

Just my 2 coppers...


Thanks,
Tommy Holden


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Wednesday, September 27, 2006 1:50 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: Embedded SQL, first steps

Always good to check for the exceptions.  Good work.

Wonder what a simple CHAIN does if there's duplicates?  Could cause some

real issues if you're chaining to one record and it's the other record 
always getting the updates.

Here's a false assumption from one package:  BPCS.
Let's have no keys on the physical file for the item master.
On any logical based on this physical let's have no UNIQUE keyword.
Let's ASSUME that only new companies will use our software and that all 
maintenance to the item master will come from our item master
maintenance 
menu option.  There will be no conversions from existing packages
allowed.

Now, in the real world someone is rightsizing from a PC based package.
And 
the PC based package has a few duplicate item numbers.  Or, someone
mucks 
up consolidating a few divisions.  Now you have duplicate keys in the
item 
master.

One of the falsehoods of doing all data integrity via programming and
not 
letting the database do any of the work.

Rob Berendt