CursorAdapter - очень эффективное, хотя и громоздкое средство с ним просто долго разбираться - получаешь невнятные сообщения об ошибках или "мёртвые" курсоры, изменения в которых, например, не отражаются в таблицах. Хотя разобраться можно и добиваться при помощи них весьма и весьма неплохих результатов!
Простая ситуация - есть пара-тройка таблиц, несколько форм использующих эти данные, что делать? Не напрягая серое вещество в дизайнере локальных видов (Local view) в критериях отбора (Where) пришем что-то вроде ...
field_name = ?pcCondition
По определённому критерию содержимое выгребаем в вид и радуемся жизни, занеся это как Local View в базу данных.
А позже в коде ...
m.pcCondition = "Condition"
REQUERY("lv_MyView1")
Пока всё замечательно, НО! Ситуация усложняется - критериев несколько, они разные и условия выборок постоянно меняются, таблиц может быть в одном случае две, в другом три и т.д. (вариантов дерьма придумать можно много ...). Можно попытаться предугадать к-во вариантов - наклепать видов и изменять в зависимости от ситуации RecordSource в многострадальных Grid. А теперь добавим в форму CursorAdapter и посмотрим, что получилось и о чудо - НАМ НАПЛЕВАТЬ ОТКУДА МЫ БЕРЁМ ДАННЫЕ! Сегодня это локальная таблица и пара-тройка локальных видов (мы меняем лишь источники), завтра пяток удалённых видов, а послезавтра баловынные юзвери хотят запросную систему и мы даём им её примитивно и легко используя конкатенацию строк и настраиваемые возможности CA . А алиас всё продолжает как в первом, так во втором и третьем случаях назваться lv_MyView1!
На мой взгляд, вы неверно ставите вопрос - не нужно противопоставлять эти два механизма - нужно дополнять ими друг-друга облегчая себе жизнь.
Я лично сравнивал Native, ODBC и XML - в первом случае всё замечательно, как будто работаешь с локальным видом который ты создал в БД, во втором - если проходящий мимо компа юзверь не выдернул шнурок - то сервер тебе ответит )), ну а третье - перегруженный текстушник, он и есть перегруженный текстушник. Повторяю - НЕ ПРОТИВОПОСТАВЛЯЙТЕ CursorAdapter и собственно базу данных и ваши dbf-файлы друг - другу - ДОПОЛНЯЙТЕ!
Ну а что же до производительности - гы-гы - я видел собственным зрением, как грамотно составленный запрос на лисе (разумно и рацонально созданные индексы в таблицах с грамотной структурой) УДЕЛАЛ такой же запрос с SQL-серверу!!! Я видел и базу с суммарным объёмом записей порядка 1,5 - 2 миллионов записей (только в главной таблице к-во было порядка 500 - 700 тыс.), всё это хозяйство вертелось на НЕВЫДЕЛЕННОМ сервере, а цеплялось 20 - 25 пользователей и знаете - всё работало! Был это 98 год и лис версии 3. Да месячный отчёт по продажам делался минут 5 - 7, но в остальном всё быстро и удобно работало.
Мое личное мнение таково - не нужно гоняться за клиент-серверной технологией, масса задач даже файл-сервер не используют на полную (ну если какой недоносок не поставил на сервер ICQ и PhotoShop [и такое бывает]).

P.S.: Разбирался я по примерам, на разбор ушло несколько часов неспешного ковыряния.