This is a real problem. I posted this issue a long time ago, see thread #236192. Never did get a solution, I ended up having to write a stored database procedure to trap when the error occurred.

If you find anything new out, please let me know.

>In the past two weeks I have had two customers that could not add new records to a DBF. In both cases we found the following:
> The record count in the header was 1 less than the file length.
> Table buffering was on.
> Listing the table to the screen with a file viewer showed a record did exist at the end of the file that did not show in the browse window.
>
>If we manually append blank with buffering off we can add a record. We put some wait windows in to step through the code and each TableUpdate() returns .t. yet the record is not really added. The fix we did at the time was to copy all records out to a temp file, zap the table and append back in. This did fix the problem. We have since put put some code in the reindex prg to check and correct the problem. Nothing fancy. Just adjust the file length or record count as needed and write the detail about it to the error log.
>
>All our customers have small, 2 - 10 station, networks in auto body shops where the hardware is not always the best and crashes happen more often than I would like. So this is not an uncommon occurence.
>
>What angers me about all this is that in DOS if any DBF had this problem you got "Not a FoxPro Database File" as soon as you opened the table. Microsoft seems to have done away with the check in VFP. I can only assume that their respnse would be "Go and buy Back Office if you want error checks"