Date   : Thu, 09 Jun 1983 04:51:00 EDT
From   : Allan D. Plehn <PLEHN@mit-mc>
Subject: Bugs in dBase II

I found the following on a local RCPM:

///////////////////////////////////////////////////////////////////////
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Listing file DBASEHNT.DOC



                ----- INSERT HINT -----------
                          donated by Charlie
                                from Orange Bytes Newsletter

        A bug has been detected useing the Insert command. It can result
in the loss of data record if a carriage return is issued at the wrong
time. (Tate knows about it but no solution yet.) So they are recommending
that you do not use INSERT and INSERT BEFORE. 
        Case in point, C.J.Thompson wrote that if you have issued the Insert 
command, after indexing to some intermediate record in your database,
you are presented with the standard data input screen with the cursor in
the first position of the first field.
        If you enter data at this point, everything seems to work as
advertised. But if you should happen to enter a carriage return (thinking
perhaps, to move the cursor to the second field), you are dumped out of
the Insert mode only to find that the record count in your database has
been incremented by one.  Further insp`,W{on reveals, however, that the
'plus one' count is the result of two events; (1) the record following
the intended insertion point has been triplicated, and (2) the next
record has been deleted. And evidently, not by a "*" but 'all gone'.
        
                ------- Goof Hint -------
                        by Charlie for Charlie

        I was going to update a members information in my Name/Address
database when I accidently entered a CONTROL CHARACTER UNKNOW into my
file and it got written to the DataBase. I had 272 records in my DBF file
but after that goof I got a OUT OF RANGE error after 24 records. After
two lousy hours of research and trial/error I finally got it back on track.
In my efforts, I learned a lot about things I really have no need for but
what can I say, maybe some day.  Anyhow, nothing worked, either in the
DBF or NDX until  (1) I added a new record (2) erased the NDX and then
(3) INDEX again. It seems to be O.K. now. The error evidently changed the
total record stored somewhere (I never found out where) but the 272 records
was always in the DBF file.

----
Local hint (from Dave)-- When you use GET and the 1st field is a numeric
        it'll probably crash, if character it's O.K. (at least for him it
        did)
Safety hint-- After working on your DBF file and you want to use PACK.
        Be sure to exit first ,to force a write to disk, then re-enter
        to do your PACK operation. Some locals have lost their data
        otherwise, but why hasn't been pin-pointed yet.

FINI for now

///////////////////////////////////////////////////////////////////////////
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\


We use dBase rather intensively at my place of employment and additional
bugs have been noted, as follows:

a) If the CASE statements are nested to more than two levels the
program will crash.

b) If two files are open at the same time, a PRIMARY and a SECONDARY,
SET LINKAGE ON command will crash the program and cause the infamous
"BDOS Error on Drive xx" error message, with the xx being a non-
existant drive.

These two bugs occurred consistantly on both the eight-bit and
sixteen-bit (CP/M86) versions of dBase II.

I would be interested in hearing of fixes or new releases of dBase II
that would take care of these bugs.

                               Al Plehn <PLEHN@MIT-MC>