Обработка DBF-файлов в моем понимании возможна 3 способами:
1. Специальными СУБД под MS-DOS (Clipper и т.д.)
Это для тех, кто может существовать без Windows, кнопок, окон и тому подобного. (Имеется в виду, что работа происходит в сеансе MS-DOS в специальном окне, а также к услугам полноэкранный режим). Если пользоваться CLIPPERом, то только версией 5.3 с оговорками (4-я слишком старая, 5.0, 5.1 и 5.2 содержит глюки при работе с DBF-файлами на ровном месте).
А при работе с версией 5.3 необходимо отказываться от системы индексирования CLIPPERа (.NTX), в которой содержатся глюки при работе с большими DBF-файлами (что-то начиная с 40 000 записей) и включать систему индексирования DBASE (.NDX), не содержащей ошибок. Это делается следующей последовательностью действий:
а) request DBFNDX // в начале главного модуля
б) rddsetdefault('DBFNDX') - до открытия DBF-файлов один раз в главном модуле.
в) при линковке указывать lib dbfndx , которая поставляется с CLIPPEROM.
Также там имеется два линкера - Exospace (типа основной) и Blinker 1.0 (дополнительный от сторонней фирмы). Так вот - для небольших и средних программ можно пользоваться Exospace, а для программ неограниченного размера - (типа расчета заработной платы) - только Blinkier 1.0. В Интернете мне удалось найти версии Blinker 5.0 и 6.0 , однако я так понял, что это какая-то СНГовая переделка, и она не может собирать большие программы (не хватает какой-то памяти).
При работе в CLIPPERе файлы обрабатываются прекрасно, но основное время программиста уходит на создание всяких редакторов этих самых DBF-файлов в виду ущербности штатного DBEdit-a. Так что этот вариант можно рекомендовать для полностью автоматизированной обработки, где
не требуется ручной обработки DBF-файлов.
Еще важное достоинство CLIPPERa- его поразительная устойчивость против внезапных сбоев компьютера. Если пользоваться оператором COMMIT - то будьте уверены, что в файл будет записано ровно то, что программа успела обработать. Я ставил эксперимент в поисках отказоустойчивой СУБД - выводил в цикле быстро меняющееся число на экран и параллельно с этим добавлял по одной записи в DBF-файл с каждый раз увеличивающимся на 1 значением. И в некоторый момент нажимал RESET, моделируя этим внезапную остановку системы. После перезагрузки компьютера я изучал содержимое DBF-файла - какая запись записана последней?
Именно при экспериментах с CLIPPERом последней записью было именно то, что успело мелькнуть на экране в момент нажатия RESEТа (проверке подвергались также PARADOX, CLARION, ACCESS, FOXPRO - файл был просто пустым).

2. Специальными программами под Windows, не использующие BDE и ODBC (CLARION, например).
Очень неплохая система, но очень своеобразный язык программирования и очень своеобразный подход, так что я изучал его с 1999 года и только в 2004 году создал первое приложения для обработки DBF-файлов. Так что можно рекомендовать лишь тем, кому с легкостью поддаются новые языки программирования. Главный недостаток - чувствительность к тому, в каком порядке идут поля в DBF-файле (программу придется перекомпилировать, если решите поменять поля местами). Так что можно рекомендовать в случае, если файлы будут со строго определенной структурой. Однако можно поступать наоборот - менять структуру DBF-файла под программу, если
ведущим в разработке является программа, а не структура DBF-файла. Этот недостаток все-таки компенсируется слишком скоростной обработкой и наличием средств быстрого создания редакторов для ручной обработки файлов. Как это делать - в версии CLARION 2.0 имеется учебничек типа "Первые шаги" в формате PDF, только прочитав который научился таки создавать приложения на CLARIONе. Без него хоть выучите язык наизусть - ничего не получится, слишком все своебразно сделано.

3. Большинством программ, использующие ODBC (хоть даже MS Office, Cristal Report). Этот подход подразумевает использование SQL-запросов, а я в этот клуб стараюсь не ходить по принципиальным соображениям (я стараюсь пользоваться индексно-последовательным способом доступа к DBF-файлам). Однако очень хорошая программа Cristal Report (пожалуй единственный нормальный генератор отчетов под Windows) заставляет меня использовать таки ODBC для создания отчетов на основе DBF-файлов. Но создание отчетов - это не обработка, хотя и очень важная часть. В Access-е можно сделать так называемую присоединенную таблицу - создать сначала пустую, а затем к ней присоединить "отдельно стоящий" DBF-файл. Дальше - создавать модуль и на Visual Basic c применением DAO (Data Access Object) (который надо еще подсоединить не забыть) обрабатывать DBF-файл через систему Аccess. После пары неустранимых глюков в Аccess-е 7, 8, 9, 10 (система зависала при попытке подчиненной формы просуммировать строки и вернуть это в родительскую форму - куда уже проще? - я отказался от работы в Ассess-е и использую его только для ручной обработки DBF.

Petr_Ch,
спасибо за совет, попробую с CLIPPER 5.2 еще раз повозиться, если надыбаю версию именно 5.2е, и вариант использования CLIPPER 5.3 попробую.
В моем варианте CLIPPER 5.2 глюк был такой - неправильно срабатывал DBGOTO(#записи).

Побывал на сайте, но ссылка на патч для clipper 5.2e как раз и не работает. Нашел на другом сайте http://www.incredibleprogram.com/html/clipper_patches.html. Там два варианта (US Version и International Version). Буду пробовать обе - может подойдет.