Ситуация следующая: имеется DBF-файл размером 120 Мб расположенный на сетевом диске.
По нему надо сделать банальный селект типа такого
Select * from table where columnname =’1111111111’.

Этот селект выполняется порядка 15 секунд.
Если DBF’ку положить локально, то селект занимает в среднем 4 секунды.
Если еще и проиндексировать по полю, используемому в WHERE, то время его отработки уменьшается раз в двадцать.
Хорошо. Если локально.
Стоит только проиндексировать DBF’ку в сетке, как никакого прироста скорости не наблюдается. Т.е. эта зараза видимо копирует все на клиентскую машину и там делает выборку. Какая именно зараза?
Пробовал пользовать три провайдера:
1. стандартный System.Data.OleDb (Provider=Microsoft.Jet.OLEDB.4.0)
2. VFP9 (Provider='VFPOLEDB.1')
3. ODBC
Первый и последний вообще индексов не понимают (скорость работы с индексом не увеличивается даже на локальной DBF’ке). Второй понимает только локальный индекс(стало быстрее в 20 раз).

Так может и нельзя быстрее-то?
Однако сам VFP6 (у меня шестерка) выборку из проиндексированного файла в сети делает без всякой задержки. Значит можно, только как?

Как можно заставить провайдер не копировать весь объем на локальную машину?
Или из C# нельзя? Только «родным» синтаксисом из FoxPro?

Вообще я слабо знаком с DBF. Поэтому может что-то не так делаю. Например, я не знаю какой именно версией FoxPro был сделан этот 120-мегабайтный DBF-файл. Судя по тому, что в нем DOS-кодировка, то видимо в какой-то старой версии FoxPro. Я же индексирую его через FoxPro 6 версии (что нашел  ). Может быть в этом может быть проблема?

Итого: можно ли средствами C# сделать быстрый запрос по большой DBF’ке на сетевом ресурсе?

Заранее спасибо!

У меня была проблема с кодировкой. Об этом ниже.
Если с кодировкой все в порядке, то VFP9 (Provider='VFPOLEDB.1') может понимать индексы у файлика на сетевом ресурсе. В результате скорость возрастает в 250-300 раз. В моем случае с 14 секунд до 0.05!

По кодировке:
Открываю файл VFP6, он говорит, что кодировка на файле не стоит, а надо поставить.
Раньше я выбирал DOS-кодировку, чтобы текст был читабельный.
Теперь же установил Win1251 - отображаются крякозяблы в колонке с русским текстом (индексировал по другой колонке, где нет кириллицы), зато подхватился индекс, лежащий рядом с файлом DBF на сетевом ресурсе! Также работает, если отменить смену кодировки, которую предлагает VFP6.

Т.е. он копирует на локальную машину индекс, который на несколько порядков меньше данных. Потом уже делает выборку по данным...

Черт, теперь траблы с кодировкой.

При работе через System.Data.OleDb (Provider=Microsoft.Jet.OLEDB.4.0) не подхватывались индексы, зато не было проблем с кодировкой.
При использовании VFP9 (Provider='VFPOLEDB.1') стали подхватываться индексы, но появились проблемы с кодировкой:

--- Test from dbf (Microsoft.Jet.OLEDB) ---
SNAME=ГОРУЛЕВ,

--- Test from dbf (VFPOLEDB.1) ---
SNAME=???"<:'

,

Т.е. через Microsoft.Jet.OLEDB отображается «Горулев», через VFPOLEDB.1 – совсем даже не то, что надо.

Если открыть эту БД через VFP6 выдается предупреждение, что кодовая страница не установлена. Предлагает установить. Если выбрать MS-DOS (866), то русский текст отображается нормально. Если Windows или нажать Отмена, то крякозяблы.

Строка подключения:
conn = string.Format(@"Provider='VFPOLEDB.1';Data Source='{0}';Extended Properties=dBase IV", path);

Пробовал так:
@"Provider='VFPOLEDB.1';Data Source='{0}';Extended Properties=dBase IV;CODEPAGE=866;"

@"Provider='VFPOLEDB.1';Data Source='{0}';Extended Properties=dBase IV;Collating Sequence=RUSSIAN"

Ничего не помогает.
Но ведь в System.Data.OleDb (Provider=Microsoft.Jet.OLEDB.4.0) проблем не было!
Не в ручную же перекодировать…

Про 29 байт читал. Но нет возможности у меня его править. DBF'ки не мои...