I have a client that is very frequently updating several VFP tables, a couple of which have a large number of indexes. From time to time the indexes get corrupt for no obvious reason. (I can confirm they are corrupt by trying to browse the table using the index, causing VFP to complain about the corruption or skipping data in the display.) When this happens it often manifests as various sorts of trouble that seem to disappear after restarting the application only to return after some indefinite time spent in the application. It as if the corrupt index causes a problem with the in-memory structures used by VFP, thus confusing VFP while not throwing an error about index corruption. Rebuilding the indexes always clears it up for an extended period until they get corrupted again.

I think one of the problems in my case is having a lot of indexes on a table. This seems to make the indexes more prone to corruption. (I created many indexes to make SQL selections run faster when they have clients on the phone waiting in real-time. In hindsight this was probably not a good idea since the tables are updated frequently. I would try to do it differently if I did it again.)

I've offered several times to work on chasing down the problem, but my client is content with rebuilding the indexes every few months and says they have never lost any data, although data may sometimes disappear until they rebuild the indexes.

...Jim

>Hi Christof,
>
>Interestingly, Chaim reports that after getting the error a simple restart of the application proceeds properly with no sign of any index error.
>
>While I can agree that this still could be a hardware error somewhere along the path, the fact that no permanent damage is done (indexes still all OK, no rebuild required) suggests that other factors are (also) involved.
>
>cheers
>
>