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

Did you do this programmatically or did someone just eyeball it?

Generally when I table scan for unexpected characters I flag all ASCII characters below 32 (space), except (optionally) for TAB in memo columns. I also optionally flag ASCII characters over 127, English typically doesn't use them, I don't know about French.

On a slightly different note, how do you know the index keeps corrupting? Can you do manual SEEKs or similar at the VFP command window and not get the results you know you should get? If that's the case, what is SET COLLATE when this table is used or accessed? http://fox.wikis.com/wc.dll?Wiki~NonMachineCollation~WIN_COM_API

I also found a CDX corruption checklist on the Fox Wiki: http://fox.wikis.com/wc.dll?Wiki~CDXCorruptionChecklist~VB

IMO a bit dated and some of the suggestions seem to be extreme edge cases. OTOH something is causing your issues, maybe your case is an edge case.