>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.


Pat,

I'd say that this is not about corrupted indexes but about "corrupted" data. I derive this from the both facts that a. your index still tells the data should be thare and b. your problem itself : the data has gone. And c. might be : an index showing the data to be there and the data not being there is normally not possible. However :

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.

Now, since you are working with LOCATEs (no SEEKs ?) nothing will tell you that the Index isn't there (if the SET ORDER isn't there also), and further logic around all may cause a record to get overridden.

If it would be my app I'd be looking for something like this first, knowing that I had never heard of a situation like this. And I haven't ...

But think of the UNIQUE clause on the Index too (like others said). In the past I learned not to use that at all, because it was too easy to let this fail. I don't know about today.