>
>Before you think too much about this being a bug, it surely urges for thinking it is just the app failing here. It just needs a combination of two things : the app skipping the Append but doing the Replace, and the Index not being attached.
>
>The latter obviously will never be the intention, but please note that it is not all that difficult to get an error at the opening of the Index file only (e.g. USE MyDbf Index MyIndex). Just stress the server with a few PC's heavyly performing the USE and Appends to the file, and add to it some wrong logic in error trapping. It may leave you with the dbf open only.

Peter,

1..Immediately after we INSERT the new record, key in all the fields, and do the TABLEUPDATE, I test the LOCATE to see if the record can be found. To date, the code has always found the record just inserted and updated. So I wouldn't think that the Append has failed, but I suppose I can't confirm the index is good unless I try a SEEK.

2..Later, while running another app that uses the same LOCATE code, we discover that sometimes records aren't found. When viewing the table manually, we confirm it is gone. When troubleshooting, we access the table from the command window and try to find the record that appears to be missing by setting an index and doing a SEEK. The SEEK returns a found()=.t., moves the record pointer midway down the table, but places it on a record that does not match the SEEK criteria. It is on a record that was created at almost the exact date and time as the original record....right where it would be if it the missing record still existed. So at that point it appears that the record which earlier had been located is now missing from the table but is still in the index. Could this be happening if the index file were not opened with the dbf as you suggest?

Pat