Лисонька1. Где можно скачать dbed.exe и нужно ли его качать?
В интернете, наверное ;)

Например, здесь

http://softsearch.ru/programs/27285.shtml
http://www.freesoft.ru/?id=502&name=multi-dbedit-v2.1-beta-(freeware)
http://www.searchfile.ru/?command=brows&id=16273

Вообще, "чинилок" файлов DBF достаточно много. Но прежде чем ими пользоваться следует убедиться, что они не испортят таблицу еще больше. В данном случае, будет ли эта програма корректно восстанавливать именно файлы DBF от VFP8

Лисонька2. Зачем делать COPY TO, если все и без этого заработало?
На самом деле, надо не COPY TO делать, а создать чистую таблицу с нуля и через APPEND FROM закачать в нее данные из поврежденной таблицы.

Хотя, все это - без гарантий. По хорошему, требуется всегда иметь резервную копию базы данных. Т.е. регулярно делать Backup и хранить эти резервные копии хотя бы за неделю.

Лисонька3. Отчего заваливается таблица и можно ли этого избежать впредь?
Сбой питания или разрыв соединения в процессе внесения модификаций в таблицу.

Избежать совсем - невозможно. Но можно существенно снизить вероятность такого события:

1) Убедится, что все железо - безглючное. В особенности сетевая и видео (!) карты.
2) Поставить блоки бесперебойного питания как к компам, так и к хабам.
3) Свести время собственно модификации к возможному минимуму. Т.е. модификации делать в буферезированных таблицах (или в копиях данных), а сохранение изменений делать одним пакетом. Одним блоком команд, который не может быть прерван пользователем (нет диалога с пользователем внутри этого процесса)

Лисонька4. В этой таблице у меня около 10 тыс. записей. Могу ли я быть уверена, что в таблице ничего не потеряно после восстановления?
Нет. Надо просмотреть таблицу глазами. Как правило, повреждения затрагивают последние записи. Т.е. те, которые физически расположены в самом конце таблицы.

Лисонька Так что лучше на уровне каждого курсора указать 5-ю буферизацию.Но тогда, пожалуйста, поясните мне выгоду накапливать новые записи в буфере, а потом "пачкой" писать их в таблицу. Чем плохо, что пользователь заполнил форму, а затем нажал либо кнопку ОК (пошла запись), либо Отмена? Или методика такова, что надо строить приложение, которое обязательно работает как INSERT INTO cursor? Это очень важно для меня на будущее - как строить новый проект.
Здесь вопрос не в том, "пачкой или по одному" происходит сброс буфера, а в управляемости этого процесса (сброса буфера).

При строковой буферизации, при определенных условиях, попытка сброса буфера может произойти автоматически. Т.е. в неуправляемом программистом режиме. При табличной буферизации такого быть не может. Сброс буфера только и исключительно программно по команде TableUpdate()

Настройка Form.BuferMode означает, что FoxPro сам решит, каким таблицам дать строковую, а каким - табличную буферизацию. Т.е. процесс сброса буфера становиться менее управляемым.

Лисонька Впрочем и использование REPLACE нетипично - обычно просто правят в соответствующих контролах данные - а уж контролы привязаны к полям курсора.Тоже важно для меня на будущее. Да, я в форме редактирования к контролам привязываю переменные со значениями полей, затем делаю lcVar1=...control1.VALUE; lnVar2=...control2.VALUE; ... , а потом уже REPLACE ... WITH lcVar1 и т.д. В чем выгода работать непосредственно с полями?
Просто удобнее. Нет лишних "телодвижений". При работе через переменные необходимо:

-) Объявить область видимости таких переменных как PUBLIC (что уже не есть хорошо)
-) Инициализировать эти переменные (записать в них данные из записи таблицы)
-) По окончании редактирования записать их значения в поля таблицы
-) Дать команду TableUpdate()

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

ЛисонькаА почему все же курсор, а не сама таблица?
В данном случае подразумевалось одно и то же. Здесь путаница с терминами.

О_В_ДНарод!
Пардонте вам за странный вопрос.
У меня таблы еще ни разу (тьфу тьфу) не падали. Но если вдруг...
Ответьте. При запуске EXE сразу выдается сообщение ...has become corrupted. The table will need to be repaired before using again... или об это можно узнать, тока когда юзер вызвал форму с DE, в которой и используется сламанная таблица?
Зависит от того, что именно было повреждено. Можешь и вообще никаких сообщений не получить, просто прога будет криво работать.

Как правило, сообщение об ошибке появляется при попытке открыть таблицу. Если не было открытия до вызова формы (не обязательно явного, например, Select-SQL автоматом откроет таблицу), то будет сообщение только при открытии формы.

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

Прежде, чем что-то начинать писать надо сопоставить: вероятность события, последствия наступления события, затраты на учет этого события, эффективность решения, ограничения накладываемые данным решением.

Так вот, 100% решения проблемы не существует. Как уже было сказано, все зависит от того, какое именно повреждение произошло.

Делать проверку всех таблиц при запуске системы можно, если таблиц немного. Т.е. если общее время проверки относительно невелико. Опять же, если таблица нужна для специфической формы, которую используют раз в месяц - останавливать всю работу? А в сетевом приложении как? Будет выгонять всех чтобы вошел кто-то один? Для проверки-то нужно эксклюзивное открытие таблиц.

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

Как правило, делают отдельную процедуру проверки как собственно структуры таблиц, так и целостности базы данных вообще. Эту процедуру запускает администратор базы данных либо регулярно (раз в неделю, раз в месяц и т.п.), либо когда есть подозрение на повреждение данных.

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

В общем, не стоит паниковать. У Вас ведь не было пока сбоев? Какие основания есть предполагать, что с завтрашнего дня сбои начнуться каждый день?