Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!wuarchive!brutus.cs.uiuc.edu!usc!bloom-beacon!apple!motcsd!hpda!hpcuhb!hpindda!keithb
From: keithb@hpindda.HP.COM (Keith Broussard)
Newsgroups: comp.databases
Subject: Re: dBASE IV Problems
Message-ID: <3520010@hpindda.HP.COM>
Date: 5 Sep 89 16:38:40 GMT
References: <205@cerc.wvu.wvnet.edu.edu>
Organization: HP Information Networks, Cupertino, CA
Lines: 55

Gentle notes users,

I can assure you that the problems that I cite in the first response of
this notes string are not the result of BAD DATA, or CRASHES.  My best
suspicion at this time is that dBase IV has some problems with
concurrency on a network.

I have followed the design of the A-T sample programs, basically
letting dBase handle file/record locking and providing locking error
trapping routines.  Thus, I can be sure that (except in the case of
memo fields which I'll talk about later), it is not I who is causing
the problems.  Besides, I've studied and debugged the code for months.

Memo fields present interesting problems because of a couple of
'realities' of dbase IV (and DOS).  First, there are no variables
equivalent to memo fields, so a user editing a memo field requires
that the record of the database be locked.  It is not possible for the
user to edit an equivalent memory variable, thus leaving the database
unlocked during edits.  Why is it important to leave the database
unlocked during edits?  Answer: it must be able to be locked
exclusively by anyone wanting to APPEND a record.

It is possible to copy the contents of a memo field to a text file,
and then edit the file, but this raises the second problem with memo
fields:  If you copy the contents of a memo field to a text file, then
edit the file, and leave the database record unlocked in the meantime,
someone else may edit the same memo field and someone's data is going
to get overwritten.  There is no way to check to see if someone else
has read the memo field since you read it.  Due to the nature of memo
fields (they invite long editing sessions) this problem is very likely
to occur.

I solve this problem by copying the memo field data to a text file
WHICH IS NAMED BASED UPON THE KEY FIELD OF THE RECORD, and make sure
to check that there is no file by that name which exists before I
start editing.  Primitive record locking, I guess.

While memo fields are inconvenient in dBase IV, they should be used
with caution and a "Let the buyer beware" attitude, I believe.
However, I find them to work most of the time.  The problem with
pointers to memo field data getting mixed up is the first OUTRIGHT BUG
that I have found with them, though.

I AM CONVINCED that there are problems with dBase IV that MUST BE
ADDRESSED by A-T.  I have had no indication that certain problems
which I and others have encountered are being addressed.  Some of
these problems are discussed in the first response to this notes
string.

Since I am sure that v 1.1 of dBase IV has had a change freeze for
many a month now, I guess I can only WAIT and HOPE for improvements in
v 1.1.  I would like to see, however, some acknowledgement by A-T that
these problems exist and are being considered by A-T.

Regards