Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ames!mailrus!umix!uunet!tektronix!reed!percival!bucket!leonard
From: leonard@bucket.UUCP (Leonard Erickson)
Newsgroups: comp.sys.ibm.pc
Subject: Re: dBase III+ (was dBSAE Fat Kil (was Re: corrupt FATs?))
Message-ID: <832@bucket.UUCP>
Date: 31 Mar 88 06:27:56 GMT
References: <2731@crash.cts.com>
Reply-To: leonard@bucket.UUCP (Leonard Erickson)
Organization: Rick's Home Grown Unix; Portland, OR
Lines: 27

In article <2731@crash.cts.com> cline@pnet01.cts.com (Ben Humphreys) writes:
<dBASE supports 1 billion records.  To my knowledge dBASE does not get 'flaky'
<around 2500 records.  Clipper on the other hand has problems around 64k limits
<when indexes are open in rare instances.  

dBase III indexes can start acting extremely weird at as few as 1400 records.
I once was called in on a problem where they'd been using SET UNIQUE ON and
then indexing on a multi-field key to eliminate duplicate records. On day the
program went nuts. out of 1400-1500 records it came up with 20 in the index.
And watching it index was shocking too. It got up to 47% indexed and then there
was a *long* pause. Then it continued indexing.... all the way to 573%!!!!

It was indeed a bug in indexing. Ashton-Tate even admitted it to us. The "cure"
was dBase III+. 

I've run into a different bug on DBII+. We've got a 100+ *thousand* record
file. It takes up over 15 meg. Both COPY TO and APPEND FROM with a FOR
sometimes fail to retrieve any records, yet the records are there. Going to
a record somewhat before the records being sought and repeating the SAME
command with a NEXT xxxx works. I'd love to know what is going on. The file
isn't indexed, it *is* in chronological order and the records are being
retrieved based on a date range. 
-- 
Leonard Erickson		...!tektronix!reed!percival!bucket!leonard
CIS: [70465,203]
"I used to be a hacker. Now I'm a 'microcomputer specialist'.
You know... I'd rather be a hacker."