БорискаGermanGM подсказал чем заменить &key() это подсказка в сторону повышения скорострельности
но вот результат возвращаемый &key() или Evaluate(key()) бутет один а нужен другой....
А вообще, откуда у вас пошла такая странная идея, что портится именно значение ключа?

В 99 случаев из ста в индексе портится структура. SCATTER/GATHER может помочь прибить проблемный узел и перестроить его на новый листовой узел индекса. А может и не помочь, если проблема не в одном только узле.

Более того, надо помнить, что структура дерева на каждом UPDATE полей становится все более высокой и рыхлой.

Полный реиндекс будет гораздо надежнее, да и повысит производительность индекса за счет снижения высоты дерева.

По самому вопросу:
1. Фокс хранит значения KEY ни разу не так, как сами данные.
2. Выдернуть это значение можно прочитав его из индексного файла.

БорискаKruchinin Pahan,

спасибо, суть вопроса как раз в том разбирать .cdx или есть более простой способ. простого видимо нет. вот только не знаю спрашивать как или лучше не надо (вдруг это крамола...)
В хелпе есть описание структуры компаундного индексного файла.

Но у меня есть подозрение, что достоверно проверить целостность индекса можно только перебрав все дерево целиком.

БорискаИгорь Горбонос,

>Кстати, как ты видишь процесс проверки?
вкратце так:
a=вычисляемое значение
в=считанное значение
if a#b
&& караул
endif
проверить все записи во всех таблицах или диапазон записей или одну это исходя из предпосылок
Нарушения значения одной конкретной записи в индексном файле не бывает. В теории может быть. Раз в сотню тысяч лет.

Как вы не понимаете, в индексах рушится структура дерева, а не конкретные значения. И восстановление "значения" в индексе требует перестроения либо всего дерева, либо части дерева.