You can't do that

[Brian K. White]

----- Original Message ----- 
From: "Jeff Harrison" <jeffaharrison at yahoo.com>
To: "Scott Brown" <lordblue at msn.com>; <filepro-list at seaslug.org>
Sent: Thursday, September 01, 2005 1:15 PM
Subject: RE: You can't do that


>
> --- Scott Brown <lordblue at msn.com> wrote:
>
>>
>> >
>> >John, you are lucky that you have not been exposed
>> to
>> >the garbage that I have seen :-)
>> >
>> >It also seems that you are getting lost with just
>> this
>> >one example.  My request was for rules for data
>> >integrity.  This would just be one of the possible
>> >rules.
>> >
>> >Example: I have seen many situations where the
>> >programmer has allowed the deletion of a record
>> such
>> >as an an inventory record, when it is still
>> referenced
>> >in another file such as an order file. Ouch.
>> >
>> >Some other possible rules would be:
>> >
>> >Force certain field(s) to be unique.
>> >Require a non-blank field.
>> >Require the existence of a matching record in
>> another
>> >file.
>> >Minimum/Maxium values for fields.
>> >Math rules for field values. (Ex. Field must be an
>> >even number)
>> >Prevent any records from being deleted.
>> >Require that if field A is filled in then field B
>> not
>> >be filled in.
>> >
>> >These are just a few of the possibilities that come
>> to
>> >mind.
>> >
>> >Jeff Harrison
>> >jeffaharrison at yahoo.com
>>
>>
>> I for one, would hope that FilePro would not put
>> these kind of limitations
>> on their software. Most of what you mentioned should
>> be taken care of by the
>> person writing the program. It's not FilePro's fault
>> if some programmers
>> can't write good code.
>>
>> Just my humble opinion,
>>
>> Scott....
>>
>>
>
> I'm not sure why you see this as a limitation.  The
> original programmer would put these rules in place not
> filepro.  It is just that filepro would attempt to
> enforce these rules.
>
> Yes, in a perfect world, programmer #1 would and
> should be responsible for not violating his own data
> integrity.  However, what is to stop programmer #2 (or
> programmer #22 for that matter) from making a mess of
> things?  There is no way for programmer #1 to  forsee
> the way that programmer #2 will mess things up.
>
> No, its not filepro's fault that some programmers do
> not write good code.  Its also not my fault that a
> second programmer came in and messed up my
> application.
>
> What is the down side of being able to make such
> rules?

It's like saying we shouldn't have edits because they limit what kind of 
data you can enter. Or a less sever example we don't need the ! an % 
characters in define screens.

I don't know why anyone has any difficulty getting what your saying or why 
anyone wouldn't agree.

Lets throw away edits and do all the equivalent work in processing, because 
you're the programmer and it's up to you to just write it how you want it 
right?
Can anyone possibly claim this would not be a huge downgrade if not a 
complete disaster?

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!