Hello everybody



we have a problem with Foxpro 2.6 Index Files.



The application was running fine for a long time but suddenly the index
files on one of the tables gets corrupted when I just touch them...



This happens only to older records (like one month old) if I copy the
record and work on the copy everything is fine.



It looks like the index file is corrpupt even before it gets obvious to
the user (record appears doubled). Querys involving this record fail.
The record seems to be fine if I open it with VFP6 and browse it with
the according index.

If I check it parallel in the application and touch the record from
there the index gets corrupted imediatly.



Does anybody know what might cause this behaviour or has anybody
discovered something similar?



I appreciate any hints...



Dennis


--
Posted via http://dbforums.com

Dennis,
Are you using .IDX indexes, or .CDX indexes? Are you or have you ever recreated the indexes in VFP?

Rick

"dchris" <member46409 (AT) dbforums (DOT) com> wrote

Hi Rick



we have CDX Index files



I tried allready different ways to fix the problem:



- reindex in fox 2.6

- reindex in VFP 6.0

- copy to with CDX type fox2x in VFP 6

- copy to with CDX in fox 2.6



The last copy to in fox 2.6 seemed to fix the problem but this was only
temporary. A few days later I got the same Problem again.



Now we tried something new:

- rewriting record by record field by field to eliminate the possibility
of corrupt fields in fox 2.6

But this did not fix the problem either.

It seems as if our Surrogat keys contain something that is not
allowed or corrupting the index allthough the key looks absolut OK in
the browse...







Thanks for any help



Dennis


--
Posted via http://dbforums.com

On Thu, 06 Nov 2003 05:58:28 -0500, dchris <member46409 (AT) dbforums (DOT) com> wrote:
[ quoting context restored; reformatted ]
Dennis,
you missed _the_ way to fix corruption in FoxPro indexes: delete all index tags;
re-create indexes. All of your ways above just propagate the problem, doing
nothing to fix it.
--
[ When replying, remove *'s from address ]
Alexandre Peshansky, Systems Manager, RUH, NY
(note last name spelling change)