I have some questions:

What version of FoxPro are you using?

What kind of indexes do you have on the table? Are you using the UNIQUE clause when you create the index?

How are you performing the LOCATE?

>My clients operate in a multi-user environment where up to 30 users manually add single records to a table on the server. At various times during the day 500-1000 records may also be programmatically added to the same table through a separate program. At some point after each record has been entered, maybe an hour or maybe a day later, each record must be edited. A LOCATE is performed to find the record, if it is not found an error message is logged.
>
>We are seeing 10-15 records a day failing the LOCATE when they later need to be edited. We know the records were not deleted, an INDEXSEEK on a unique field returns .t., and a manual SEEK places the cursor on record in the table that doesn't match the SEEK criteria. This seems to indicat that a record appears to be in the index but not in the table.
>
>A few days ago we wrote some code to perform the same LOCATE as described above immediately after adding the record and log the results to a separate table. All of the logged results show that the LOCATE immediately following creation of the record were successful confirming that the record made it into the table. But we are still seeing the records later fail to be LOCATED. My guess is that a record subsequently added is somehow removing an old record in the table and corrupting the index.
>
>We can't force the failure, it just seems to be random.
>
>So the question is; does this sound like the bug having to do with corrupted table headers (thread 580276)and if so are the workarounds limited to manually locking the file and doing a FLUSH as each record is added, or is it something else with a different fix.