Несоответствие версий клиента и сервера (COM-соединение) #677381

Здравствуйте! Есть два компьютера-сервера. На них установлены серверы 1С:Предприятия разных версий, назовем компьютеры соответственно 8.2.17 и 8.2.18. На компьютере 8.2.7 установлены обе "клиентские" платформы: 8.2.17 и 8.2.18. В списке баз данных на компьютере 8.2.17 прописана две базы, которые располагаются на разных серверах. В зависимости от того, какую я выбираю базу, запускается соответствующая серверу 1С:Предприятие платформа автоматически. Это все умеет 1Сestart.exe. Все Ок. Теперь проблема. Из запущенной программы 8.2.17 я пытаюсь сделать выгрузку данных при помощи "УниверсальногоОбменаДаннымиXML" путем прямого подключения к базе-приемнику. При подключении выдается сообщение "... Несоответствие версий клиента и сервера ..." с указанием таких версий, что становится ясно, что подключение к серверу осуществляется той же версией платформы, из которой я делаю выгрузку. А в идеале хочется, чтобы создавалось новое соединение при помощи другой платформы (8.2.18). Кто-нибудь сталкивался с таким? Есть ли выход из ситуации, кроме как приводить в соответствие версии серверов 1С:Предприятие?

При обращении к COM-объектам используются записи в реестре (в том числе полное имя файла, содержащего COM-объект). При установке платформы 1С записи в реестре обновляются и указывают уже на последнюю установленную версию. Если нужно подключиться к базе на сервере с 18-й версией, установи ее заново на компе, на котором выполняешь обмен. При этом потеряешь возможность подключаться через по технологии COM к базам на сервере с 17 версией. Если нужно подключаться и туда, и туда, то задумайся над исправлением реестра с помощью reg-файла или переустанавливай платформы. Еще можно выполнять обмен с разных компьютеров: один для подключения к 17-м базам, одни - к 18. Но в любом случае, ИМХО, это изврат.

Сравнять версии конечно не предлагать?

Это само собой напрашивается, видимо, проблематично.

Так ситуация была такова. Изначально был только сервер 8.2.17. База-приемник располагалась тут же, в файловом режиме. Так что проблем не было. Далее появился еще один сервер. Вторую базу перенесли на него, установив там сервер 8.2.18. С первого сервера, естественно, новая база запускаться не стала из-за разных версий платформ и серверов 1С:Предприятие. тогда установили платформу 8.2.18. Обе базы стали запускаться без проблем, за исключением COM-соединения. Это я к чему? К тому, что платформа 8.2.18 была установлена на  компьютере 8.2.17 последней.

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

regsvr32 ТС спасет

regsvr32 "C:Program Files (x86)1cv828.2.18...incomcntr.dll" как-то так :-)

, : Зарегистрировал. Перезапустил платформу. То же самое: При попытке соединения с COM-сервером произошла следующая ошибка: {Обработка.УниверсальныйОбменДаннымиXML.МодульОбъекта(13649)}: Ошибка при вызове метода контекста (Connect): Произошла исключительная ситуация (V82.COMConnector.1): Несоответствие версий клиента и сервера 1С:Предприятия Различаются версии клиента и сервера (8.2.17.169 - 8.2.18.104), клиентское приложение: COM-соединение

Новый COMОбъект(<Имя>, <ИмяСервера>) Нет под рукой "УниверсальногоОбменаДаннымиXML", можно посмотреть в нем не предусмотрено ли создание на "не локальном" компе, или поправить создание объекта указав вторым параметром имя сервера с 18ой версией. Дальше надо будет еще немного поплясать с настройкой СОМа на сервере, но это уже гуглится.

Попробуй еще снести полностью 18-й и поставить по новой.

Но мне так помогало, правда у меня ситуация была наоборот - на компе стояла более новая чем на серваке.

там еще в списке баз может явно указано 8.2.17

: Сейчас буду разбираться. , : Ясно, буду пробовать. : Не совсем понял, о чем речь.

говорит о том, что в свойствах зарегистрированной базы можно указывать точную версию платформы, которую должен запустить стартер. Но я очень сомневаюсь что СОМ-соединение проверяет это. Именно из-за того что зарегистрировать можно только один экземпляр ОЛЕ-сервера.

: А, ну конечно, при чем тут зарегистрированные базы в списке выбора информационных баз. Поискал какие-то параметры обработки универсального обмена, ничего похожего на выбор версии не нашел. Хотя это и логично.

Я бы в коде поискал "Новый COMОбъект("V82." и посмотрел передается ли туда второй параметр. Если нет то просто прописал бы его, если да - раскручивал бы как он определяется.

Второй параметр такой: Новый COMОбъект(<Имя>, <ИмяСервера>) Тип: Строка. Имя компьютера, на котором надо создать указанный объект. Если параметр опущен, то создается на данном компьютере. Ради любопытства попробовал указать имя сервера - приемника. Но я слабо представляю, как может создаться объект на другом сервере, это же необходимо авторизоваться на нем и т.д. В общем, это было подтверждено сообщением "Отказано в доступе"

Дык я ж написал в "Дальше надо будет еще немного поплясать с настройкой СОМа на сервере, но это уже гуглится." Вот тут например написано:

Отчитываюсь о проделанной работе и кривизне моих рук :-) То, что описано в - сделали. Но все равно при попытке подключения пишет "Отказано в доступе". Много всякого перепробовали, но безуспешно. Волевым решением было принято доводить версию сервера 8.2.17 до версии 8.2.18, такой же, как и на втором сервере. Был обновлен сервер 1С:Предприятие. Переустановлена еще раз клиентская платформа 8.2.18. Запустили. Но при обмене все равно ссылается на устаревшую версию 8.2.17. Из этого сделал вывод, что переустанавливать сервер было не обязательно (хотя конечно желательно). Потом удалили все упоминания 8.2.17, заново переустановили 8.2.18. Теперь при обмене ругается на "При попытке соединения с COM-сервером произошла следующая ошибка: Недопустимая строка с указанием класса". Ну, думаю, в этом я уже "профессор". Но танцы с бубном вокруг regsvr32 "C:Program Files (x86)1cv828.2.18.104incomcntr.dll" не помогают. Пишет, что выполнено успешно, но соединение все же не устанавливается по той же причине. Удалял регистрацию с использоваением ключа -u, затем снова регистрировал. Запускал командную строку от прав администратора. В общем, пока безуспешно.

Сервер - Windows Server 2008 R2 64. Проблем с регистрацией dll, таких, о которых пишут в сети, не было.

Причем все клиентские платформы всех установленных версия были удалена, а затем была установлена 8.2.18.104. Это я к тому, что "переустановить платформу" - не помогает.