Evaluating opinions - FilePro Error Messages

[GCC Consulting]

> -----Original Message-----
> From: filepro-list-bounces at lists.celestial.com 
> [mailto:filepro-list-bounces at lists.celestial.com] On Behalf 
> Of Bill Vermillion
> Sent: Friday, June 04, 2004 8:13 AM
> To: filePro Mailing List
> Subject: Re: Evaluating opinions - FilePro Error Messages
> 
> On Thu, Jun 03, 2004 at 06:17:27PM -0400, Fairlight thus spoke:
> 
> > On Thu, Jun 03, 2004 at 04:55:26PM -0400, Jay Ashworth, the 
> prominent 
> > pundit, witicized:
> 
> > > On Thu, Jun 03, 2004 at 04:41:30PM -0400, Nancy Palmquist wrote:
> > > > Fairlight wrote:
> 
> > > > > Tecnically yes. However, how hard would it be to actually put 
> > > > > code in fP that prevents one from modifying the key 
> field(s) of 
> > > > > the lookup index to prevent people from making the mistake at 
> > > > > all? I shouldn't think very difficult, since it knows exactly 
> > > > > what fields it's dealing with.
> 
> > > > Never support this in a million years. After I attach 
> to a record 
> > > > with a lookup, why should it not allow me to change a KEY field 
> > > > any way I want. How does it know what I will do next? You are 
> > > > asking it to change a fundemental feature, to protect bad logic.
> 
> > > I concur entirely.  That's not the proper solution.
> 
> > I was thinking off the cuff. After Nancy went into it, I could see 
> > that it was a bad solution. I was trying to think of a way 
> to prevent 
> > the programmer from shooting themselves in the 
> foot--especially ones 
> > just learning.
> 
> I have a question so I can understand a bit better. When it 
> was mentioned "after I attach to a record with a lookuup, why 
> should it not allow me to change a KEY field any way I want".
> 
> Does this mean the key field in the looked up record, or the 
> key field in the record from which the lookup is being made.
> 
> If the latter that violates one of Codd's 12 Rules.  
> Modifying a key that has references to that key loses any 
> referential integrity and if the looked up record has any 
> other references to it, which
> might reference the first you lose your integrity.   
> 
> I've written code in the far past to ensure that keys are 
> never modified if anything that uses those keys is extant in 
> the database after being called in to find out what data the 
> client knew was
> there could not be found.   That was to make FP act more like a
> relational database.
> 
> Bill
> 
> --
I Have written code which breaks the rule of changing the reverence key.  The
simple way to handle this is to place the original key in a dummy field and use
that for the lookups to the other file.  Or, place the new key is the dummy, do
the lookup using the key field, change the key in the daughter file.  Since one
is changing the key, I will assume that the changed record does not have to be
referenced again by a getnext.  The getnext will get the next record matching
the key. The very last thing is to change the key in the current file.

I have used this technique for changing customer codes when necessary. When
standing on the billto file:
	1. change the code in the shipto file
	2. change to code for orders
	3. change the code for invoices

 I have also used this for correcting Invoice # problems when they have arisen
(granted for accounting systems one would not do this, but mine are billing
systems to generate invoices and are not meant for accounting, most of my
clients are factored).

Richard Kreiss
GCC Consulting