You're probably right - I must have too much Yankee in my blood - for example - I prefer mainspring watches to digital ones.

It could also be an embeded end of file marker in a key field! I am never sure what those macro engines (like re-index) do. On my apps, when the users run the file maintenance modules - the utiliy deletes all the TAGs, SORTs on the primary key to a scratch file, ZAPa the original ffile, then appends the SORTED stuff back from scratch - and INDEXs each TAG. Maybe I am more than Yankee - maybe I'm just a bit too retentive:) Thanks for the update Jim!


>Hmmm... Warren said that a REINDEX brings the indexes back in synch.
>
>Now a REINDEX effectively does an internal DELETE TAG ALL and then rebuilds indexes based on the TAG info saved before deleting it.
>Since the index **IS** repaired by the REINDEX, why in the world would the other way provide any better result????
>
>To me there is far too much FUD spead here about REINDEX. I'd bet that 99.9% of the time REINDEX works just fine.
>
>Now, my only guess on this problem by now is that the .CDX inquestion is not a "structural" index, but I freely admit thatit is a VERY long shot indeed.
>
>
>
>>I think Sergey's advice is good. Open Locations.dbf. In the command window, type LIST STATUS TO MyFile.TXT (this is your list of associated TAGS and their KEYs. Then [for each tag], DELETE TAG MyTag. Then Index (not reindex) each tag according to the KEY specifications in MyFile.TXT.
>>HTH
>>>All indexes are CDX's as the table name like location.dbf and location.cdx.