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

SET TABLEVALIDATE

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

Почитай описание структуры таблицы в статье HELP

Table File Structure (.dbc, .dbf, .frx, .lbx, .mnx, .pjx, .scx, .vcx)

Написать собственный фиксер на эту проблему достаточно просто. Там даже приведена формула расчета физического количества записей. А в заголовке таблицы количество записей храниться в байтах с 4 по 7 включительно (читать справа налево)

UrriВот почему я, например, с большой осторожностью пользуюсь dbc, сильно задумываюсь перед тем, как на уровне БД прописать лишнее RI и совсем не пользуюсь автоинкрементами: да потому что у меня нет четкого представления, как все индексы, связи, целостность и значения счетчиков восстановить в случае сбоя в какой-то одной таблице.
Кто имеет системный подход и ему есть, что сказать? Кто знает ссылки по теме? Welcome!
Не надо путать невосстановимые повреждения данных (самих DBF-таблиц) и повреждение структур, основанных на данных (индексах CDX).

Логика восстановления индексов (CDX) достаточно проста:

-) Создается образцовая структура (все таблицы и индексы) или же просто резервная копия базы данных
-) В случае повреждения индексов, все испорченные файлы CDX просто удаляются. На их место коипруются нужные файлы CDX из образцовой (или резервной) копии. Поскольку их стурктура корректна, то открываем таблицы (USE ... EXCLUSIVE) и просто переиндексируем (REINDEX) для приведения содержимого индекса в соответсвии с содержимым таблицы.

По поводу самого файла контейнера базы данных (DBC, DCT, DCX)

Этот файл вообще не должен модифицироваться в процессе работы приложения. Для этого просто нет никаких причин. Поэтому его ремонт заключается в элементарном копировании всех этих 3 файлов из образцовой (резервной) копии.

А вот восстановление собственно данных (DBF и FPT) - это задача которая в принципе не может иметь универсального решения. Да, есть ряд наиболее распространенных повреждений (например, несоответсвие записей в счетчике и их реального количества). Для них можно написать фиксеры. Но в общем случае восставновление решается ручным просмотром содержимого файла на низком уровне. Поскольку заранее просто невозможно предсказать, как именно будет повреждена область данных.

UrriОК, хорошо, пусть даже мы решили, что последние введенные в битую таблицу данные восстановлению не подлежат, но у нас есть вчерашняя копия таблицы. Но на битой таблице автоинкремент, плюс она связана (с ограничениями целостности) с другими таблицами, в которых уже насоздавали ссылок на убитые данные. И как практически правильнее это восстанавливать?
Да при чем здесь автоинкремент и наложенные ограничения! Это вообще дело десятое.

Представь, что у тебя есть комплекс таблиц вообще никак между собой не связанные в контейнере базы данных. Каждое значение поля ты формируешь в самом приложении путем прямой модификации (ну, как в DOS-приложении).

И что ты будешь делать если "слетит" одна таблица?

Либо просто восстановишь резервную копию на вчерашний день, либо будет очень много ручной работы. Невозможно что-то здесь автоматизировать.

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

А есть гарантия, что слетела только одна таблица? Разумеется нет. А сколько времени потребует ручное восстановление? В зависимости от сложности базы данных и степени повреждения от пары минут, до пары дней.

Т.е. по сути, для достаточно сложных баз данных выбора вообще нет. Только восстановление из резервной копии. В сложных системах дешевле ввести все данные заново, чем ждать пару дней, пока кто-то вручную восстановит потерянные данные (причем еще далеко не факт, что восстановит!)

Пропустил, причем много чего.

-) Документ - это не одна запись в одной таблице. Обычно это комплекс, связанных между собой таблиц. Есть гарантия, что побилась только одна таблица?
-) Есть гарантия, что побились только 2 записи?

Т.е., если сбой произошел, то надо проверять ВСЮ базу данных. ВЕСЬ комплекс таблиц. Ты сейчас вот здесь вот эти 2 записи подправишь, а через пол-года выясниться, что оказываеьтся слетели данные еще где-то в другой таблице.

А как реально можно проверить корректность ВСЕЙ базы данных. По большому счету - никак!

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

Подкручивать счетчик автоинкремента нет никакой необходимости. Надо будет просто изменить тип поля на обычный Integer для внесения изменений (автоинкрементные поля невозможно модифицировать), а потом восстановить Integer (AutoIncrement) со старыми настройками. Или править код записи на низком уровне.