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