× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



You're right.  Using drop downs, etc is important.

One difference is when you do the validity checking.  You asked if we have 
the RI error blow up and sit there in a user message.  No.  In the sample 
RPG code I pasted earlier I alluded that after a write, or update, you can 
check the status code (which is probably how this whole debate got 
started).  If the status code says it's an RI issue you can retrieve 
messages from the job log and handle accordingly.  Now, you may want to 
name your RI constraints to something human readable.  Or, for language 
independence, use a message id as the constraint name.  Suppose your 
constraint name was USR0001.  Then consider the following:
CREATE TABLE ROB/WALLROFF 
  (MYKEY INT NOT NULL, 
   MYDATA CHAR (30 ) NOT NULL, 
  CONSTRAINT USR0001 CHECK (mydata>'a' and mydata<'zzzzzz'))
Now if I do a 
INSERT INTO ROB/WALLROFF VALUES(1, 'z9')
I'll see, among the SQL0545, a CPF502F in the joblog.  Suppose you did a 
rpg write.  You'd see a file status code of 1022.  And, with some api's 
you'd see the same CPF502F.  And part of the message data would contain 
the USR0001.  You could handle it from there.  You could even evaluate 
your joblog for multiple CPF502F's, and handle accordingly.  If USR0001 
blows your mind you could name the constraint Invalid_Data_Mydata.  Lean 
towards ease of programming, ease of reading the joblog, or a compromise 
between the two, as befits your shop.
The thing is if you switch from a 5250 interface to a web browser you do 
not have to redo the validity checking.  Or, if you do, and a different 
constraint is added you do not have to both update your interfaces to 
handle this new constraint.  Oh, you may want to, (for cursor positioning, 
etc), but you have the option to have a general failure occurrence.  Much 
like you should use Monitors around most of your rpg code, but a generic 
error handler might not be out of the question for stuff you didn't think 
of.

You are also safeguarded when you merge that new acquisition into your 
database, or when that one programmer tries a bad UPDDTA 'for the quick 
fix'.  Or that quick fix SQL statement.  Or...

I think we're starting to come together.  I think where we differ is on 
the validity checking, (not to be confused with prompting for values). 
You're saying do it all in the HLL, and in each HLL that updates the file. 
 I am saying that you could do it strictly with the constraints.  Others 
might say do it with hll coding, but check the write for RI violations as 
a last resort.  Some might say do it all in the HLL and assume that any 
error on the write is a dup key error.  Others might say they use 
'application level security' and the only possible access is via the one 
program.  And, in their 30 years of coding they have never keyed an error 
when using UPDDTA with their super level of access.

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





John Wallroff <JWALLROFF@xxxxxxxxxxxxxxxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
10/06/2004 02:03 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
"'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx>
cc

Fax to

Subject
RE: Write statement






No Rob, 

I wouldn't do that.  At the point of writing a record I'd have already
ensured that the user has entered valid data, by the time I write the 
record
I've already done the check.  Don't you do any validity checking at input
time or are your entry programs just blind, blank screens that let your
users enter in what ever data they happen to think might be right?  You've
no prompt programs that pop up and allow a user to pick a code from a list
of valid codes.  No drop down menus that have a list of valid selections 
to
pick from.  No scan screens to allow them to pick a valid entity, and no
validity checking when they hit the submit button or the enter key to make
sure what they've entered is valid making them fix it before allowing them
to get past the entry screen???

I'm not saying not to use RI in your database design, RI is a good thing 
but
it doesn't replace good coding it's just a backup to it.  What do you 
think
can be done automatically?  I suppose if one of your programs try to write
to a database file and hit an RI constraint problem then your program just
blows up, sits there with a message that your operator has to answer 
and/or
pass on to you the programmer?  If you code properly the user won't be 
able
to enter invalid data.  I mean, this is really the only time you need to 
do
heavy validity checking.  That and at times when you are perhaps 
integrating
data from outside your system.  If you're getting data problems during 
your
batch processing then you have way more problems then RI is going to fix 
for
you.

Again, I believe that RI is important, it is a backup to good coding and 
the
odd chance of bad data getting into your system through 3rd party entry
points like data utility programs such as DBU.

John.

-----Original Message-----
From: rob@xxxxxxxxx [mailto:rob@xxxxxxxxx] 
Sent: Wednesday, October 06, 2004 1:24 PM
To: Midrange Systems Technical Discussion
Subject: RE: Write statement

I disagree.  Why should we do everything manually when it can be done 
automatically?  In other words, in your 'good code' when you write an item 

to the item master do you first check to see if the item class exists? 
That the gl account for the item class, which is stored in the item class 
file, is a valid GL account?  An so on and so forth, up the tree?  I bet 
not.  However I once had a customer lay out requirements that we had to do 

exactly that.  And on a DOS PC with just the freebie basic supplied.  (And 

there was a response time specification also.)

And why use a key on a file when anyone who can write 'good code' can do a 

perfectly good bill of material's explosion using a chain chase sequence 
with direct files?

I have seen files with keys on the item master that didn't even specify 
unique.  And the ASSUMPTION is that all maintenance is done via the one 
file maintenance program.  However in these days of mergers, etc, that 
assumption will bite you in the end.  Or, heaven forbid, you have to work 
with others.  And the team mentality may have updates coming from a C/S or 

web based application.  They won't be using your file maintenance program. 

 But you're saying that all code should be duplicated in all programs that 

access that file.  I say horse hocky.

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





John Wallroff <JWALLROFF@xxxxxxxxxxxxxxxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
10/06/2004 11:20 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
"'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx>
cc

Fax to

Subject
RE: Write statement






OMG, that whole "Assume" analogy is so 70's.

I think the biggest problem is with programmers that think their database
design takes the place of good coding.  Referential constraints are meant 
to
be a last line of defense in database maintenance.  They don't take the
place of good program code.

-----Original Message-----
From: rob@xxxxxxxxx [mailto:rob@xxxxxxxxx] 
Sent: Wednesday, October 06, 2004 10:56 AM
To: Midrange Systems Technical Discussion
Subject: Re: Write statement

Is that the ONLY condition that will cause it?  I don't think so.
What other conditions may cause such an error?
- File full
- Duplicate key
- error on the trigger program associated with the file
- referential constraint error.

I think the biggest problem we have in getting developers to start using 
triggers, constraints and basically coming out of the 70's with their 
database design is a fear that they will have to bring their coding out of 


the 70's also.

Goes back to the basic lesson:  Assume can be broken down into three words 


A$$/u/me, or, you make an a$$ out of u and me when you assume.

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





MWalter@xxxxxxxxxxxxxxx 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
10/06/2004 10:45 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Fax to

Subject
Re: Write statement







Duplicate Key on an Unique file.

Thanks,

Mark

Mark D. Walter
Senior Programmer/Analyst
CCX, Inc.
mwalter@xxxxxxxxxx
http://www.ccxinc.com


 
                      "Dwayne Allison" 
                      <Dwayne.Allison@aaga        To:       "Midrange 
Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx> 
                      i.com>                      cc: 
                      Sent by:                    Subject:  Write 
statement 
                      midrange-l-bounces@m 
                      idrange.com 
 
 
                      10/06/2004 11:42 AM 
                      Please respond to 
                      Midrange Systems 
                      Technical Discussion 
 
 




Hello All,

What condition will cause '50' to equal '1'?


Operation    Factor 2                             LO
WRITE        ARREC                                50

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.






--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


NOTE:  This electronic message and attachment(s), if any, contains
information which is intended solely for the designated recipient(s).
Unauthorized disclosure, copying, distribution, or other use of the 
contents
of this message or attachment(s), in whole or in part, is prohibited 
without
the express authorization of the sender of this message. 

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


NOTE:  This electronic message and attachment(s), if any, contains
information which is intended solely for the designated recipient(s).
Unauthorized disclosure, copying, distribution, or other use of the 
contents
of this message or attachment(s), in whole or in part, is prohibited 
without
the express authorization of the sender of this message. 

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.