I'm accessing a dBASEIV database which is owned by another application. That other application does not evaluate the deletion indicator but relies only on the index. In order to delete a record, the node needs to be removed from the index. I have implemented such an extension based on that what is done in update() in the same programming style (patch3.diff). When I debugged Index.delete() I discovered that the comparison in Index.delete() must be
bkey.compareKey(activeKey) == 0 and not != 0 (patch4.diff). I assume, this is a bug in Index.update() as well.
I think, it makes sense, to include that extension into the product. In this case the same extension needs to be done for DBF.undelete() as well.
Furthermore I cannot see why delete() locks the whole file and not just the record, Maybe delete(boolean lock) and undelete(boolean lock) should be added as this has beed done for update. Index files are not locked at all. I hope this does not cause problems in a mutli-user environment?!
Feedback appreciated.
Extension of delete() for index update
Bugfix
can't accept this. this is not how the original dbase design works. even if a record is deleted the index entry is kept so that it is possible to refind the record and undelete it.
patch4.diff is not correct.
What the method is doing is this -
if the record # changed {
// no - we are still working on same record
if the record's key changed
remove old index string value reference
add new index string value
else do nothing
else // new record
add new index string value
patch4.diff is related to my implementation of Index.delete(). For that method it is correct and has been tested sucessfully. But I agree with you, the same change should not be applied to Index.update().
First, since the record is not physically deleted and is available for un-deleting and searching it makes no sense to remove the index of that particular record; it would break the search rules.
By offering the delete indicator dBase was designed to restore a record by simply flipping a switch. It's always been there. And so it remains.
Second, with today's release the delete and undelete methods locks the record space and not the entire dbf.