попробуй открывать рекордсеты (по "документс", или из SysObj), и выполнять movelast (или циклом по всем). по крайней мере, при открытии таблицы и попытке перехода "через" сбойные записи ошибка возникает. Да, еще и агрегирующие запросы по всем записям должны приводить к ошибкам. Типа "select count(*) from...

#Ошибка# обычно выводится во всех записях ниже (не всегда) действительно ошибочной. "Сортировка" помогает выловить (визуально). Еще накладывается то, что при выводе без сортировки записи выводятся якобы по первичному ключу, а в индексе (после восстановления) могут и отсутствовать записи с "ошибками". При насильственной сортировке (не по индексу), читается вся таблица без каких-либо ухищрений.

А сервер какой? (Новел, небось?).

обычно нет уж особой необходимости точно вытащить все живое - восстанавливается ночная копия и вперед.
А так... - когда-то выдергивал запросами с разными порядками сортировки, подбором верхней/нижней границ набора данных. (В сессию забивалось до 300-400 записей и заставить юзарей перебить все наново - не получалось).


ЗЫ: Как интересный факт, могу припомнить, что заливка больших порций данных в индексированную таблицу формата MSA2.0 из MSA97 (по сети) иногда стопорилась (по всем наблюдениям было похоже, что индекс пытается построиться на не сохраненную запись - "ум за голову заходит"), при небольших порциях, или сносе индексов из таблицы назначения все проходило тихо и спокойно.

1. Серверная ОС? (а в новелле - всякие ручки с максимальным количеством того-то и сего-то).

2. Переместить комп в сети (физически переткнуть) - результаты?

3. Расположение .mdw (устойчивость нахождения по сетке) - можно перекинуть копию .mdw на этот локальный, переподключиться, и проверить не отваливание ли сети (диска с .mdw) приводит к таким проблемам.

4. Наличие транзакций? (соответственно с настройками сервера на максимальное количество чего-то там). Обычно, правда, приводит просто к ошибке и откату (если предусмотрено).

И т.п...
...n. Замена компа? приводит ли к результату?

ЗЫ: не думаю, что мой опыт уж очень велик:)

А что ватсоны пишут? (и прочие логи)
- ведь если сетка моргает при записи, то оно, мне кажется, к кривизне должно приводить.

По сути: в процессе записи в файл мы пишем что-то не то. Обычно при незавершении записи (физическое выключение сервера). У вас: Или ошибка вносится в сетке, (кстати, а само приложение не виснет? не выгружают ли его пользователи через таск менеджер?), или что-то шумит в компе. Первое выглядит вероятнее. (т.к. зависимость от сетевой загрузки).

1. что сказал ватсон? (и евент логи) а. компа б. сервера.
__

По поводу домыслов:
шуметь может сетевая. очевидно - в клиенте. (раз зависит от него). Может шуметь оператор - закрывать приложение как не положено.

Если грешите на приложение - выясните, какая последовательность действий ведет к проблеме. (Именно этого оператора). Подумайте, не может ли сетевая работа выбросить приложение на необрабатываемую ошибку (блокировки таблиц и т.п.). (Наблюдалось падение (принудительно закрытие ОС-ой) 97 "целиком" в некоторых случаях необрабатываемых ошибок). И далее в этом духе. Попробуйте наконец расставить сообщения в подозрительной процедуре с записью протокола в файл. Да, чуть не забыл, где-то видел приладу, читающую периодически .ldb на предмет предсказания падения. Может найдете в сетке?