>>>>>>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.
>>
>>I did a SCAN programmatically for every caracter below 32 and over 122 in all character fields.
>>
>>I notice the index corruption by setting the index (SET ORDER TO), SEEKing the record I want, browsing the table and scrolling down the grid. At one point, the cursor jump back a couple of records above and keep looping. For exemple, it will reach record #100, down arrow, go back to record #95 and keep looping around 95 to 100 indefintly when I keep pressing the down arrow.
>>
>>SET COLLATE is set to General everywhere (in code and in all tables).
>
>Can you show us the expressions for all the index tags for that table (or at least that problematic tag in your example)? Any extra clauses such as UNIQUE?
>
>I would look closely at those, and the actual data in (per your example) rows 100 (especially) and 95. I believe default collation is MACHINE, if you're using GENERAL then you may also need to evaluate those index expressions in light of that collation i.e. the FoxWiki link above.
>
>It's been a while since I last had to deal with index corruption, but my general recollection is the examples I've seen have caused "record is out of range" errors, rather than any looping behaviour such as you've described.

Here's all the index on the table, no unique, no filter, all regular, all collate General :
SET ORDER TO DTPREL2 && DTPREL
SET ORDER TO ETAT && ETAT
SET ORDER TO ETATTM && ETATTM
SET ORDER TO ID && IDCARTE
SET ORDER TO IDCARTE && NO_PARTEN+STR(IDCARTE,2)+DTOC(DTPREL,1)
SET ORDER TO NO_FACTURE && NO_FACTURE
SET ORDER TO NO_PART && NO_PARTEN
SET ORDER TO NO_PARTEN && NO_PARTEN+DTOC(DTPREL)+STR(IDCARTE,2)
SET ORDER TO NOCDC && NOCDC
SET ORDER TO NOCOMM && NOCOMM
SET ORDER TO NOFACTUREA && ALLTRIM(NO_FACTURE)
SET ORDER TO PARTFACT && NO_PARTEN+NO_FACTURE