Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!violet.berkeley.edu!steve
From: steve@violet.berkeley.edu (Steve Goldfield)
Newsgroups: comp.databases
Subject: Re: dBASE IV Problems
Message-ID: <1989Sep1.233118.17414@agate.uucp>
Date: 1 Sep 89 23:31:18 GMT
References: <1989Sep1.153527.3489@xenitec.uucp>
Sender: usenet@agate.uucp (USENET Administrator;;;;ZU44)
Organization: University of California, Berkeley
Lines: 25

In article <1989Sep1.153527.3489@xenitec.uucp> timk@xenitec.UUCP (Tim Kuehn) writes:
I wrote the first:
>>In general, once I get the bugs out of a program, I find
>>that most of the problems users have are caused by bad
>>data, either entered by them or created by a crash.
>
>Bad data? How, in a properly written program, can a USER enter BAD DATA?
>And even if the stuff the user entered was out to lunch, how could a database 
>package which is writing the record to the dbf file screw the dbf file or the
>indexes up? In such cases it's *still* the dbms responsibility to take care 
>of keeping everything straight!

I was going beyond the bad index problem. The most common user
complaint I receive is: "I entered the data into the database but
your program doesn't find it." Almost invariably, I find that the
user mistyped some data (which no reasonable data verification
could catch--things like misspelling the name of a company or
mistyping an account number). They are always very apologetic
when I find the problem. At first, such a problem looks like a
possibly bad index, until you find out that the program did what
it was supposed to do with incorrect data. I only raised this
point because one can save a lot of time reading code if he or
she makes sure the data is what it was supposed to be.

Steve Goldfield