Понятно возмущение.
Но нужно просто взглянуть на проблему с другой стороны.

SQL Server не работает со строками. Он работает с данными, размещенными страницами по 2кб, и для того чтоб по ним перемещаться, он использует B-Trees на уровне ядра.
DBF файл - это всегда 1 таблица. База же SQL (не BLOB) - это непрерывная (в пределах устройства/файла) цепочка 2кб страниц данных, на каждой из которых может начинаться или заканчиваться та или иная таблица. В свою очередь информацию об этих границах сервер хранит в других структурах, которые образуют так называемые страницы распределения, или страницы индекса, если они есть. Чтоб попасть на эти страницы, ядром опрашиваются другие - системные страницы.
В общем "дерево". И выбор осуществляется путем перемещения "вверх по дереву". Индексы определяют по каким веткам нам лезть, чтоб потом не возвращаться.
При желании, можно считать это недостатком SQL, но на сегодняшний день - это самый прогрессивный подход к реализации поиска записей в РЕЛЯЦИОННЫХ СУБД.
Хотя и не кажется мне, что бы MS написали ядро способное одинаково эффективно работать со своими и DBF-овскими таблицами, есть конечно надежда напороться на желаемую недокументированную возможность. Основываться она может на следующем факте: При выборе значений отвечающих определенному условию, SQL Server заполняет массив смещений, по которому затем перемещается (ВНИМАНИЕ с помощью ISAM подобных операторов вроде GetNext и GetPrev!
P.S. Значит не все потеряно? Ищем, а?

Ключевые моменты: Database Manager, Page Manager, Search Manager, Access Methods Manager, Buffer Manager, процедура qualpage, B-Tree.
Дополнительно: DBCC SHOWCONTIG (тоже кстати НЕ для DBF)