SERGE_BLIZNUK Цитата: бесплатный от Микрософт Microsoft OLE DB Provider for Visual FoxPro
через ADOConnection, есть ADOQuery
И тут такие проблемы заимеешь, что мало не покажется.
Подвох первый: более-менее прилично в Delphi можно работать с ADO версии не ниже 2.6, а это – Windows 2000 и позднее. Для остальных нужно устанавливать пакет MDAC, который весит от 5 Мб и выше. Подвох второй: ADO – это технология работы с SQL-данными. А поэтому, если вдруг в dbf-таблице отсутствует первичный ключ, уникальный для этой таблицы, то вам гарантирована масса острых ощущений типа «не удается найти строку для обновления», а потому получите большую дулю вместо записи данных и т.п. Выражаясь «по-умному», ADO требует выполнения правил 1 нормальной формы (1НФ) для любой таблицы, с которой работает. Кто не знает, что такое 1НФ – читайте Дейта. Но ладно бы только это. Еще один подвох в том, что с любой таблицей ADO работает через SQL-запросы. А это означает, что если, допустим, понадобилось в чисто dbf-ном стиле пройтись с начала до конца таблицы размером, например около 200 Кб, около 300 записей, и установить какое-то поле в true (или false), то это займет не меньше 500 mS, а если поиграть с настройками в "нужную" сторону - больше 10 секунд (на celeron-2000)! Поскольку для каждой записи ADO состряпает SQL-запрос примерного вида
Update table1
Set MyField = true where id = N000
Где N000 – для каждой записи свой, на формирование, проверку запроса и его выполнение нужно время и т.д. и т.п. Удручающая картина, не правда ли? В то же время, если орудовать в стиле SQL, т.е. потребовать – «чтобы у всех записей в таблице table1 поле MyField было true», т.е.
Update table1
Set Myfield = true where true
то это сработает за сотые доли секунды на той же таблице (30-70 mS). Для сравнения: Halcyon 6.9.6 на той же таблице отрабатывал за примерно 60-80 mS, т.е. фактически то же время. Вывод: ADO – не для dbf. Это для SQL-серверов. Причем не для всех.
. Есть такие в природе?