Добрый день! Это мое первое сообщение в данном форуме, прошу извинить, если невольно отступлю от принятых традиций.

Кратко о проблеме: com-соединение между двумя базами 1С, расположенными на разных машинах.

Есть проблема. Имеются три базы, 2 - файловые 8.1, 1 - серверная 8.2. Эти три базы служат "донорами" данных для четвертой "сводной" базы (8.2 - файловая)

В "сводной" базе, по мере необходимости запускается обработка, которая выкачивает данные из предыдущих трех баз, используется com-соединение, объект V82.COMConnector и V81.COMConnector (для соответствующих платформ). Все работает прекрасно, пока файловые базы физически находятся на одной машине, ну и сервер 1С - на ней же (все это стоит на Win 2008)

Возникла задача: убрать сводную базу на другой сервер №2, находящийся далеко, за границей. И ВСЕ, никакими путями не получается установить соединение между базами, не смотря на указанный второй параметр - ip-адрес удаленного компьютера.

V8 = Новый COMObject("V81.COMConnector", АдресСервераБД);

Трудно вспомнить все попытки настроить, в данный момент ошибка следующая "class is not registered" в момент соединения по инициативе базы сервера №2 к базам сервера №1 (неважно, к файловым или серверной базе). Это сообщение относится к серверу №1, с которой пытаемся установить соединение. На самом деле классы на нем зарегистрированы, т.к. локально на сервере №1 сводная база продолжает работать. И на сервере №2 локально - все работает нормально - com-соединения с локальной базы с локальными - осуществляются корректно.

При любой попытке обратиться  из бд машины №2 к бд на машине №1 - соединение не осуществляется.

После многих поисков в интернете, сложилось впечатление, что ни у кого не стояло подобной задачи. Во всех "примерах работы с com" даже наличие второго параметра (адреса com-сервера) не упоминается.

Прошу подсказать возможные решения проблемы именно тех людей, кто решал подобную задачу или хотя бы точно знает, что подобное соединение работает, НА ПРАКТИКЕ.

С уважением, Роман

>>Com-соединение между базами 1С через интернет
Это как так??
Вы в курсе, что COM работает только в одной сети?

(0) ком через интернет работать не будет,
используйте VPN или распределёнку

Почитайте про работу COM, и чем она отличается от маршрутизации.

(2) _3 не вам.

(2)>>используйте VPN
тогда уж пусть делают выделенный канал. Надежней будет.

Спасибо за оперативный ответы!

VPN сделано - могу, например, указать путь к базе на удаленном компьютере \\192.168.0.3\d$\base\ (правда, работать невозможно в таком варианте, тормозит), но com-соединение

Новый COMObject("V81.COMConnector", "192.168.0.3");

возвращает ошибку. Теперь вот что-то типа: "сервис RPC не найден"

В описаниях по com и dcom я нигде явно не встретил сведений о том, что все это работает только в одной сети.

"DCOM через интернет и решение проблемы XP SP2
В 2009 году DComLab опубликовал коммерческий продукт ComBridge. При использовании ComBridge для работы по DCOM через интернет не требуется CIS, не используется 135 порт, в локальной сети не требуются настройки dcomcnfg. ComBridge встраивается в транспортный уровень DCOM, полностью выделяя весь трафик созданного объекта и всех полученных из него объектов в отдельный поток."

dcomcnfg настроен?
На веб-сервисах написать обмен не думал?

И еще интересно то, что текст сообщений об ошибке на машине, с которой осуществляется соединение - изменяется, в зависимости от настроек удаленной машины. Если на удаленной машине отменить регистрацию класса или остановить сервис RPC - то ошибки в момент соединения отличаются вариантами. Это означает, что попытка соединения все-таки происходит. В системном журнале так же возникает ошибка DCOM, именно:

Параметры разрешений для конкретного приложения не дают разрешения Локальный Запуск для приложения COM-сервера с CLSID
{24FF4FDC-1D9F-4195-8C79-0DA39248FF48}
и APPID
{B292921D-AF50-400C-9B75-0C57A7F29BA1}
пользователю NT AUTHORITY\система с SID (S-1-5-18) и адресом LocalHost (с использованием LRPC). Это разрешение безопасности можно изменить с помощью служебной программы управления службами компонентов.

Вообщем, готовых инструкций, видимо, нет :(

(6)а у вас что - ComBridge работает? Делайте выделенку.

Придется, видимо, переписывать все на веб-сервисах. Просто работы очень много

(8)>>Это означает, что попытка соединения все-таки происходит
это значит всего-навсего - что компонентов DCOM столько, что ошибки возникают в разных местах, но по одной причине.

(6) Если VPN поднят подключайся к базе как обычно. Не нужен тебе никакой DCOM

Да ладно, расковыряй уже эту ошибку, тут же в правах дело

(12) как это как обычно, если она на другой машине?

цитату про ComBridge я упомянул в том смысле, что из контекста фразы следует, что com-соединение, теоретически, должно работать не только в локальной сети. Хотя об этом я и так знаю, когда-то писал программу на Дельфи из пяти строк, запускающую MS Word на чужой машине из другой сети, создающую пустой doc-файл и сохраняющую ее на локальном диске.

Тут действительно дело в настройках прав, я думаю. Скорее, нужен спец по dcom. Знание встроенного языка 1С не поможет :)

(14) Ну а ты толстым клиентом как подключаешься к Серверу приложений или путь к файловой? Правда для локальных баз DCOM предпочтительней. Можно использовать прослойку для соединения с базой написанной на другом языке. А начинать надо с настройки DCOM

Кстати если работал с Delphi то там помню был TSocketConnection суть его была в том, что на сервере загружалать прога, которая подгружала нужный ком объект и через IDispatch организовывала транспорт по Tcp/IP и хранение ссылок на объекты. Если есть проблемы с COMConnector
можно самому написать самому сервер который будет подгружать "V81.COMConnector". То есть можно решить через прослойки

(15) а если просто прописать базу как обычно и открыть в режиме предприятия?

Кстати тебе проще работать через v81.Application для V82.COMConnector  нужно создавать COM+ сервис http://www.steeltrace.ru/details/articleid/22/регистрация-1с-com-компонента-для-работы-с-64-битными-приложениями.aspx , так как вызывается DLL

При этом все равно нужно свести в минимуму количество вызовов, поэтому лучше организовать внешюю обработку которая будет передавать данные через ХранилищеЗначения
Дерево список итд, что будет сериализоватся и не будет объектам хранения в БД (справочники,Документы ..)

Сжатие = Новый СжатиеДанных(9);
Хранилище = Новый ХранилищеЗначения(Тз, Сжатие);
СтрокаXML=XMLСтрока(ХранилищеКартинки );


и на клиенте

Хранилище = XMLЗначение(Тип("ХранилищеЗначения"), СтрокаXML);
Тз= Хранилище.Получить();

УРА. Сердечное спасибо всем откликнувшимся. Решена проблема, на которую было убито куча времени. Теперь файловая база на иностранном выделенном сервере нормально подключается ко всем трем базам (две файловые 8.1 и одна серверная 8.2) на московском сервере и качает нужные данные.

Правда, был сделан vpn при помощи KerioVpnClient и использованы рекомендации Serginio1 (19-сообщение в этой ветке). Еще мешал встроенный брандмауэр на win2008 на московском сервере, хотя, вроде бы, не должен был.


Думаю, при помощи этих рекомендаций возможна настройка соединения и без VPN, но к сожалению, мне недоступны настройки аппаратного комплекса защиты сервера (брандмаэура), а взаимодействие с человеком, который управляет сетью и железками - затруднено. Поэтому моя битва без VPN была проиграна :)

Спасибо всем!