Как известно, бывают COM-сервера 2-х типов: dll и exe. Dll запускается как процесс на том же компьютере, что и запускающий его процесс. Exe - на компьютере, указанном в настройках COM-сервера или с адресом, переданным параметром функции CREATEOBJECTEX (). Смотрите “Task Manager” в обоих случаях.

Вы недостаточно точно объяснили ситуацию, не написали код и описание ошибки. Я могу предположить, что первый COM-сервер выполнен как dll (или как exe, но с настройками запуска на компьютере клиента). А на компьютере клиента почему-то не видно 3-его компьютера (со вторым COM-сервером). При этом с компьютера, где установлен первый COM-сервер, второй COM-сервер «хорошо» виден. Таким образом, в одном случае первый COM-сервер запускается на «родном» компьютере, в другом – на компьютере клиента. Вообще, с COM-серверами много приколов, не все из которых хорошо объяснимы. Код и описание ошибки многое могут прояснить. Если, например, нет доступа (очень часто бывает), то компьютер, по крайней мере, однозначно «виден», и надо точно копать в правах.

Я встречался с похожей ситуацией запуска COM-сервера через посредника (там везде COM-exe с настройками запуска на «родных» для exe компьютерах). На всех компьютерах работало, на одном нет. 3 вечера вместе с системщиком бились, так и не поняли, чем отличается тот компьютер от прочих.

Я, честно говоря, не очень много работал с SQL-серверами и совсем не работал с OLE DB технологией. Но принципы работы, мне кажется, я понимаю. С технической точки зрения фишка SQL-серверов и программ, поддерживающих OLE DB-технологию, в том, что они всегда (!) выполнены как DCOM-сервера (Distributed – распределённая модель!). Ну, или как-то так. Таким образом, если Вы подключаетесь к 1С через OLE-DB провайдер (!), то Ваш запрос никак не может выполняться на клиенте, хотя объект подключения и создаётся на нём (на клиенте). И никакой посреднический COM-сервер Вам не нужно писать в принципе. У Вас и так всё круто. Поправьте меня, если я ошибаюсь.

Если у Вас ДРУГАЯ ситуация, в которой всё же желателен посредник, то написать его (COM-сервер на Visual FoxPro) можно. Я лично писал сам, с нуля. Подскажу, если чё. Но это, как бы, шаг назад. Дело в том, что технология COM – Component Object Model (модель объектных компонентов) оперирует объектами, как видно из названия. В базах данных принято оперировать таблицами. В этом основное неудобство. Нужно будет постоянно преобразовывать таблицы в массивы или строки и обратно. Я не использовал никогда XML. Но думаю, если уж писать COM-сервер, то использовать возможности XML для такого рода преобразований, потому как это межъязыковой и прочий стандарт.

Не понял. Зачем писать COM-сервер, если он избыточен? Кроме этого COM-сервер, должен будет возвратить, очевидно, данные клиенту. Как? Какими курсорами? Не может объект (COM-объект) возвратить курсор! Только строку или другой примитивный тип данных!

Дима ТМожет. Как строку через FILETOSTR() и STRTOFILE()
Я так и делал. А передавал данные параметрами: одномерными или двумерными массивами. Я и говорю, что это – УСТАРЕВШИЙ подход. Стремиться надо к XML, очевидно, как к стандарту. Но, возможно, рентабельнее будет по-старому.

Проходящий2 Рома Б.
Не надо вводить в заблуждение. Драйверы, в том числе и OLEDB, на то и драйверы, чтобы работать на машине клиента. Это не серверы. То, что они умеют ходить на сервер еще не означает их запуска именно на сервере.


Спасибо тоже. Не знал. Я, как бы, писал, что не уверен. Просто человеку 3 дня никто из специалистов не отвечал. А я хоть что-то, но знал. Меня смущало, что при подключении к MS SQL из FoxPro через драйвер ODBC запросы выполнялись на сервере, а не на клиенте.

Насчёт XML. Ну да, здесь тоже не прав. Полистал про XML. Надо пользоваться старыми функциями: STRTOFILE () и FILETOSTR ().