shtuzerПри всем при этом индексы падают по несколько раз в сутки. Судя по всему при попытках одновременной записи в таблицы
Судя по всему, может быть. У меня, например, такая фишечка имеет место быть.
Я не говорю, что у вас именно тоже самое. Отнюдь! Просто, для примера расскажу.
В принципе, у меня всё как и у вас. И таблицы dBase III (FPD, CP-866) в нетвари, и приложения для FPD, и особо продвинутые сотрудники "дёргающие" те таблицы посредством VFP, и индексы иногда слетают.
Почему рушатся? Так я причину ту всё ж таки сыскал. Причина была в приложении FPD или в использовании VFP без учёта особенностей родного приложения - это как кому больше нравится, так пусть и сочтут для себя лучшим.
Шутка юмора (в моём случае) заключалается в том, что добавление новой записи в родном приложении не происходит как оно считается правильным для приложений обрабатывающих данные не в эксклюзиве, не монопольно то есть.
Нет в том приложении последовательности типа:
APPEND BLANK
GATHER MEMVAR
но имеет место примерно такой случай:
APPEND BLANK
REPLACE POLE_1 WITH VAL_1
REPLACE POLE_2 WITH VAL_2
.......
........
ля-ля тополя
........
REPLACE POLE_3 WITH VAL_3
........
и что самое обидное, вот там где точечки есть и READ-ы, и дополнительное вычисление обрабатываемой записи (чтобы, типа, не напутать куда потом добавить).
Так вот. "Грамотный" сотрудник (или программист), использующий VFP для работы с данными приложений FPD, ни чуть не заботясь об имеющихся "странностях" работающего приложения, начинает "грамотный" слив данных в таблицу....
Забавно то, что приложение FPD безошибочно, но не предполагает, что может использоваться другой "алгоритм образования новой записи" и этот "алгоритм" иногда умудряется впихнуть запись вопреки (а точнее - полностью брезгуя) используемую "методику". В итоге: и то, и это - оба варианта правильные. Идентификация каждой записи в совокупности не нарушается. Данные не пропадают. Но индексы падают. Причём здорово так падают! Ка-а-ак заклинит всё, нафик, что аж до консоли сервера дело доходит. Ибо иначе пользователя ну никак не снять.

автор DOS , конечно, физически не предназначен ни для чего другого, кроме FAT 12/16 и максимум 2-х гиг на физическом /логическом диске
Почему? Разве кто-то уже запретил Extended DOS Partition? Или я не понял: к чему тут упоминание "физического диска" ?

А меня, лично, умиляют эти ссылки на предельный размер dbf-файла (2 ГБ) у foxpro. Это только о-о-о-чень великий ум программиста может создать систему, использующую такую таблицу, что она таки может достичь предельного размера. Где? Вы скажите мне в каких таких задачах возможна одна таблица такого объёма? И неужели, если даже такое возможно, нельзя завести другую (вторую) таблицу с данными, и обрабатывать не одну, а две? Это сложно? Может быть. Но легко - только умереть. Вот это, млин, запросто.
И знаете ещё что. Когда разработчик не пожелал потрудится над проблемой человека (а человеку иногда надо и отлить и попить, а не вечно за компом сидеть), то не для человека он сочинял, а ни для кого. Так, отработал по факту, денег взял и был таков. А вы - пользователи - мудохайтесь с тем программистским изобретением как хотите.