Evaluating opinions - FilePro Error Messages

[Bill Vermillion]

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

-- 
Bill Vermillion - bv @ wjv . com