Xref: utzoo comp.databases:1905 comp.sys.ibm.pc:23861
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!uoregon!rankin
From: rankin@uoregon.uoregon.edu (6eorge Rankin.)
Newsgroups: comp.databases,comp.sys.ibm.pc
Subject: Re: Official dBaseIV Anomalies
Summary: dBase bugs are really nasty for SQL.  Will Ashton-Tate fix them?
Keywords: dBASE anomalies bugs
Message-ID: <3658@uoregon.uoregon.edu>
Date: 28 Jan 89 21:13:30 GMT
References: <3035@silver.bacs.indiana.edu>
Reply-To: rankin@uoregon.UUCP (6eorge Rankin.)
Followup-To: comp.databases
Organization: University of Oregon, Computer Science, Eugene OR
Lines: 64

In article <3035@silver.bacs.indiana.edu> regoli@silver.bacs.indiana.edu (michael regoli) writes:
>
>][
>
>what follows below is the "official" listing of dbaseIV anomalies as
>taken from ashton-tate's bulletin board.  the file, ANOMALY.ARC, was 
>downloaded on 23 january 1989.  .......

To summarize:  dBASE IV has some "anomalies"  

   *a)  If a table is more than %95 physically (?relational?) sorted
        and is indexed, joins to that table can miss entries.

    b)  Under some conditions, a query may fail on tables with more than
        5000 entries.  (SQL reports an "internal error".)

    c)  Under some conditions, joins of two indexed columns may fail
        with an internal error.

Item "a" is rather horrifying...

>In keeping with our commitment to provide you, the user, with support
>that will maximize your productivity with the dBASE IV product, we are
>continuing our tradition of publishing timely, detailed anomaly and 
>work-around reports.

But will they offer free fixes to the program?  These are very serious bugs,
and would make me very wary  of using their system.  "Work-arounds" don't
do much good when a program produces incorrect results.  Imagine telling
your payroll department that the reason some (unknown) employees didn't
get their paychecks is because "your table was more than 95% physically
sorted on a field, but less than 100% sorted, and it was indexed.  Of
course you had problems!"  Any good payroll department would immediately
scrap the computer system and issue checks by hand.  No kidding. 

The dBASE IV SQL errors are the most serious that any computing system
can be guilty of.  Before flaming, think about it for a minute.  A
program that produces incorrect results is far worse than one that crashes.
In human terms: the answer "I don't know" is far preferable to a made-up
answer.  Furthermore, systems that sometimes fail are far worse than 
those that always fail.  It looks as if a DBASE IV SQL database could
fail for mysterious reasons after working well for many months.  This
behavior is almost impossible to debug, especially when it is the database
and not the user's application that is at fault.  

Ashton-Tate should at least be congratulated for publishing the errors
to the extent that they have.  (Will they mention them in their next
set of advertisments for dBASE?)  Professional ethics require them
to fix these problems and supply the fixes to their customers.  The
idea of a "workaround" reminds me of the old joke:

      Patient:  Doctor, it hurts when I do this.
      Doctor:   Well, then don't do that!

Relational databases are a wonderful idea.  Let's not give them an
undeserved reputation for being unreliable.


	George Rankin
	Senior Programmer
	Springfield Public Schools

"We have used Oracle for many years and are quite happy with it, even
 though the C precompiler is atrocious."