Для интеграции 1С и FoxPro (изменения в 1С должны быть отражены в Фоксе) я создал механизм прокси-объектов для работы с фоксом в контексте 1С. В результате все возможные операции чтения, записи, изменения и удаления у меня реализованы через подключение VFPOLEDB.
Я использую следующий вариант подключения




Далее, я преобразую обращение 1С в sql запрос и выполняю его через данное подключение.
Понятно, что вся работа с таблицами фокса происходит на локальной машине, у меня есть мысли как вынести выполнение на сервер, но до этого еще далеко.
Так вот, все работает вроде бы прекрасно, на локальных файлах. Но когда обращаюсь к базам расположенным в сети, время выполнения запроса вырастает в десятки раз.
Подскажите, что может быть причиной? Может быть в строку подключения нужно добавить ряд параметров, необходимых для оптимизатора, может проблема в трафике или серверном железе.
Индексы. Первая мысль была что у меня не используется индексные файлы, тем более программисты foxPro сами бояться использовать sql синтаксис, и используют исключительно внутренние механизмы типа SEEK. Но я эту мысль старательно отбрасываю, потому как новые записи у меня индексируются, а битый индекс (если вдруг найдется) сразу выдает ошибку.
В ходе эксплуатации обнаружил еще одну проблемку: выполнение запроса через VFPOLEDB сильно грузит клиентскую машину и элементарный запрос типа select * from ... where .., возвращающий 200 записей может прерваться от нехватки памяти.

Подскажите, пожалуйста, в чем может быть проблема?

Да, про 200 строк я сгоряча упомянул, я знаю как происходит выполнение запроса.
По поводу кодировок -- видел Ваш давний пост. у меня такие результаты:
?CPDBF -- 866
?IDXCOLLATE(здесь я ставлю порядковый номер индекса) возвращает MACHINE

Кстати, заметил такую вещь, после выполнения запроса select * into cursor ... ?CPDBF стал возвращать 1251, а ?IDXCOLLATE вообще ничего не выдает

По поводу моего запроса. Я его строю динамически.
Например в select - where я обычно передаю только список однозначно определяющих полей. В таблице фокса индексов много, на все случаи жизни. Иногда мой список полей совпадает с одним из индексов, иногда избыточен или вообще иной.
В случае insert и update я вынужден прописывать все поля таблицы, если нужно чтобы поле было пустое -- я передаю значение по умолчанию для соответствующего типа данных. Например для пустой даты я передаю CTOD('//').

Правильно ли я понимаю, что для того чтобы индекс использовался, например в select, нужно в условие подавать список полей, соответствующее одному из индексов? Но что тогда делать например с запросом insert?

Dima T,
Спасибо. проверю свои запросы на соответствие индексам.

ВладимирМ,
Спасибо, помогла именно кодировка. условие where пока не критично, но на случай сложной таблицы буду оптимизировать по составу индексов. Я не совсем понял, что значит F1+F2 = (...)
Допустим у нас есть таблица, колонки С1, С2, С3, С4. Есть индексы С1, назовем его I1 и С1 + С2 - соответственно I2. Имена индексов в случае sql запроса к драйверу бесполезны. говоря, что необходимо ориентироваться на состав индексов при составлении запроса, я имел ввиду следующее. Если у нас условие С1 = 1 И С3 = 1, то я так составляю запрос where (C1=1) and (C3 = 1). Если условие С1 = 1, С2 = 1 и С3 = 1, то запрос where ((C1=1) and (C2=1)) and (C3 = 1). На самом деле по ANSI условие where должно читаться и применяться справа налево, но похоже оптимизатор vfp9 на это не смотрит, т.е. порядок не важен. Поэтому скобки которые я наставил - они лишние. В дальнейшем я хочу добавить обработку условий or, not, операции сравнения, и вот для этого случая я хочу чтобы мой механизм добавлял скобки в соответствии с индексами.
А что имели ввиду Вы?

Последний пример я не совсем корректно привел. Хотел написать так


Это я к тому, что сперва проверяем фильтруем по максимальному индексу, потом применяем последующие после чего пишем оставшееся условие по которому индекса не существует (если оно есть),