Прошу прощения, что запостил это сообщение в данный топик тоже (помимо топика про C#).
Дело в том, что данный вопрос на стыке C# и FoxPro. И судя по всему не самый простой вопрос.
Специалисты по FoxPro - может подскажите, куда думать?


Ситуация следующая: имеется 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’ке на сетевом ресурсе?

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

Вы правы!

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

Однако подхватил индекс не OleDb (Provider=Microsoft.Jet.OLEDB.4.0), а VFP9 (Provider='VFPOLEDB.1'). ODBC тоже подкачал – не смог пдхватить.

Спасибо большое!

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

При работе через 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'ки не мои...

Я бы с радостью :)
Дело в том, что есть большое количество DBF'ок на сетевом диске, которые в общем случае обновляются каждый день. Каталог с DBF’ками с правами только на чтение. С этими DBF’ками может работать несколько (много) экземпляров приблуд, которые я собственно и хочу научить эффективно работать с DBF’ками. Копировать DBF’ки на каждую машину и менять там 29 байт не эффективно. Клиентов много и объем DBF’ок большой.

Выбираю пока из двух вариантов:
1. Использовать провайдер Visual Fox Pro 9 (Provider='VFPOLEDB.1'), чтобы умел работать с индексами. Но при этом использовать ручное перекодирование.

2. Заюзать Оракл, который там уже развернут для других целей. Т.е. при старте приложения морда определяет, что DBF’ка изменилась (по хэшу например) и всасывает эту DBF’ку в Оракл с помощью BulkCopy. Файлик весов 120 Мб усасывается в Оракл примерно за минуту. Как бы терпимо, но вот если этих файликов хотя бы пять? Долго. Создать индекс на DBF’ку, если его нет, как бы значительно быстрее и пользовать потом напрямую DBF’ки…

Нельзя в них писать. И доступа нет.
А грузить в Оракл тоже не вариант в общем случае однако. Т.к. одну-то большую DBF'ку можно за минуту грузануть. А если их несколько? Это сейчас надо подключить только одну. Что будет со временм не понятно. Так что нужно докручивать вариант с индексами.

Большое спасибо всем откликнувшимся!

Нет возможности поднять вебсервис на той машине, где лежат DBF'ки. Закрытый сегмент и все тут. Безопасность, бла-бла-бла. Можно эти DBF'ки только читать и при необходимости индексы создавать/пересоздавать. Все.

А Оракл развернут на другой машине. Его можно пользовать. Только вот смысла особого нет...

Да, на машине с Оракл можно развернуть "свою" структуру БД на DBF'ках. Однако хрень редьки не слаще: что в Оракл импортить, что копировать DBF'ки на другую машину - требуется время. Хотя в случае копирования, это время меньше конечно. Но поди объясни заказчику, зачем это надо :)
Типа работают же имеющиеся проги с этими DBF'ками? Работают (сделаны на FoxPro 2.5 и клиппер). Значит можно "быстро" пользовать имеющиеся DBF'ки? Можно. Все остальное значения не имеет. Он, заказчик, не хочет париться из-за проблем разработчика. И он в общем то прав.

Есть еще вариант написать все реально на фоксе и пользовать его как OLE-сервер. Так вроде можно...

Или вручную перекодировать.
Однако тут еще "неожиданно" встает вопрос не только про поддержку cdx-индексов, но ntx-индексов (клиппер). Причем не только читать такие DBF'ки, но и создавать и пересоздавать такие индексы. С созданием cdx-индексов я думаю справиться можно через провайдера VFP9. Но вот ntx-индексы! Я в шоке :) Их даже сам VFP6 (среда разработки) не понимает...