Path: utzoo!attcan!utgpu!watmath!xenitec!timk
From: timk@xenitec.uucp (Tim Kuehn)
Newsgroups: comp.databases
Subject: Re: dBASE IV Problems
Message-ID: <1989Sep1.153527.3489@xenitec.uucp>
Date: 1 Sep 89 15:35:27 GMT
Reply-To: timk@xenitec.UUCP (Tim Kuehn)
Organization: Xenitec Consulting Services, Kitchener, ON
Lines: 62

steve@violet.berkeley.edu (Steve Goldfield) writes:
><135@cica.cica.indiana.edu> mr@cica.cica.indiana.edu (Michael Regoli) writes:
>#>keithb@hpindda.HP.COM (Keith Broussard) writes:
>#>
>#>>1.  Indexes seem to get corrupted so that large chunks of data are
>#>>often skipped during sequential searches, or cyclical repetitions of
>#>>records occur.  I.E.  An alphabetical listing will skip all names
>#>>between R and V, for example, or a list will get to Z and start again
>#>>at C, over and over and over...
>#>
>#>i've been experiencing this as well.  i'm *damn* glad that i'm
>#>not alone in this.  
>#>

...stuff deleted....

>#>--
>#>michael regoli
>#>mr@cica.indiana.edu 
>#>regoli@iubacs.bitnet
>#>...rutgers!iuvax!cica!mr
>
>I've seen similar behavior in all versions of dBASE, including
>McMax, I've used. Generally, these problems are caused by
>abnormal exits from the program through hard or soft crashes.

Or just *bad software*. I had a AT version of dbIII+ running a tracking 
application on a computer that at irregular interval (phases of the moon,
president's cramped little toe, who knows?) the index's would get all
confused and/or the database would have some records that were *totally*
bad (a record of control characters and other misc garbage). Accessing that 
record would cause the package to go to never-never land, and cause me
untold hours of time fixing the problem by writing a program that would,
record-by-record copy the old database to a new database, skipping over
the offending records, a process which often took at least an hour. (And 
since I'm a contractor who lives about 20 min. away there's the travel time
both ways too....on a Saturday or Sunday morning...grrr...)

Interesting thing - on the same machine, with the same program using 
Foxbase/+ I *never* had that problem again.

...stuff deleted...

>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!

...more stuff deleted....

+-----------------------------------------------------------------------------+
|Timothy D. Kuehn	       			       timk@xenitec	      |
|TDK Consulting Services			       !watmath!xenitec!timk  |
|871 Victoria St. North, Suite 217A					      |
|Kitchener, Ontario, Canada N2B 3S4 		       (519)-741-3623 	      |
|DOS/Xenix - SW/HW. uC, uP, DBMS. 		       Satisfaction Guaranteed|
+-----------------------------------------------------------------------------+