Kurzenev,
Перетирали это много раз. Повторю еще...

Kurzenev
Повредились записи БД за определенное число и те записи, в которые вносились изменения тоже за это же число (к примеру, за 16.12). Суть повреждений - в MEMO-поля записан мусор или они пустые. Строковые, даты и т.п. поля остались без изменений.

Первое - отчего так повредилась база?

База данных, основанная на файлах DBF, "крутится" на обычном файловом сервере. Это значит, что за запись данных отвечает сервер, а за их обработку - "толстый" клиент. Естественно, что в момент, когда запись уже началась, а свет вдруг "вырубился", в файл будет записан всякий мусор. Ибо ресурсов у сервера недостаточно для корректного завершения запущенных сеансов.... Мемо-поля по размеру больше, чем другие (кроме General) и редактируются чаще. Поэтому на них эффект "виднее"... А "выстрелить" (запортить данные) могло в любом месте... На моей памяти был такой случай, когда программа выдала текстовые данные в файл DBF вместо принтера, чем этот файл "убила"... Благо это был справочник и его восстановили с резервной копии...

Kurzenev
Второе- кто виноват и как этого избежать?

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

Kurzenev
Разработчиков уже нет, но в коде программы (вскрыта REFOX'ом) отсутствуют механизмы BEGIN TRANSACTION-END-ROLLBACK.

Вы немного не понимаете специфику FoxPro и пытаетесь на него "натянуть" стандарты специализированных серверов SQL. Все таки программа, написанная на FoxPro, это не сервер, а "толстый" клиент (пусть и со своим движком SQL). Минимальные транзакционные механизмы у нее есть (например, различные типы буферизации), но они бесполезны, когда сбой происходит на файл-сервере. Кроме того, встроенных автоматизированных механизмов "поднятия" актуального состояния базы данных (как, например, протоколирование изменений, проводимых пользователями) у Фокса нет, а, будучи запрограммированы на языке FoxPro, они сильно замедлят работу программы... Подумайте сами, не зря ведь продавцы берут хорошие деньги за дистрибутивы MS SQL SERVER или Oracle... :-)

Резюмируя вышесказанное:
1. если Вам критично Ваше приложение (например, программа - уникальный продукт), то вложите деньги в повышение надежности: грамотный админ на файл-сервере, хороший компьютер (на роль сервера) / специализированный сервер за несколько десятков тысяч "зеленых", обеспечение бесперебойного питания файл-сервера и т.д. надолго избавят Вас от подобных проблем.
2. если Вам критичны работы по поднятию БД, то вложите деньги и переведите имеющуюся базу на SQL-сервера (MS SQL SERVER или Oracle), доработав соответствующим образом клиента или написав нового...

Хотя я лично не уверен, что поднятие БД SQL-серверов при подобных ЧП будет быстрее и пройдет безболезненно для данных (т.е. ничего не потеряется из того, что пользователи вводили в момент непосредственно предшествовавший ЧП)...