>>>We have an index that keep corrupting all the time. Even if I delete the table, rebuild it from scratch and recreate the indexes, the same index will eventually corrupt itself again. Allways the same index and allways the same table.
>>>
>>>Except for power failure or application shutdown in a middle of a write, what can cause this ? And how to avoid it ?
>>
>>I don't know if this has already been suggested, but I've seen cases where bad characters in table data (e.g. CHR( 0 )) can cause index corruption. These are sometimes caused by power failures or app/workstation crashes as you've mentioned but they persist in the table data, so they cause problems with indexes.
>>
>>You may want to scan the table(s) in question (char and memo columns) for CHR( 0 ) or other characters that shouldn't be there.
>>
>>If you're deleting the table, the backup you're restoring or APPENDing from may have this sort of corruption.
>
>I've done a scan of the table for any CHR (0) in any string fields and didn't found a thing. All the numeric and date fields seem OK also.

Under vfp6 we had lots of problems with buffered tables, transactions and CHR(0). We used views a lot (as CA came later), but I don't know if views were part of the problem. We ditched transactions and automatic triggers and CHR(0) was gone.

We did NOT try to re-enable those features under vfp8 or vfp9, so cannot say if it was fixed there.

So if you use transactions or dbc-based RI/automatics, try to disable them for a test.
RI better handled via SQL shown in one of the Hentzenwerke books.