Ранее на сервере виндовс было развернуто 2 базы рядом. Из одной базы подключались по com к другой и формировали отчет по объединенным из двух баз данным.
Сейчас переехали на linux, соответственно com подключение невозможно, если правильно понимаю. Как можно подключать к базе вместо com ?

Сделать из двух баз одну?
Сделать обмен на других инструментах?

(0) Подключайтесь по http

Прикольно наблюдать наступание на грабли.
Уже хз сколько утверждаю что "COM is deprecated!"

Т.е. не используйте обмены через COM/OLE даже если сервера и компы на Windows
Переходите на другие методы, например http-сервисы или обмены через файлы, если в брокеры и очереди сообщений не можете

(0) Написать Native API ВК для 1С под Linux?
Которая будет эмулировать COM-соединение

(3) просто все тупо сидят внутри типовых виндусовых баз, а вменяемого очевидного инструмента нет.
На COM стащили у друзей готовую обработку и пилят ее дальше по шаблону.

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

Поэтому сесть на досуге и осваивать эту тему как-то не очень получается.

А тут точно также сидели-сидели... пока вдруг на линукс-сервере не пересели.

(3) Это ж надо мозг перестраивать, думать надо что база должна отдать и как. Это тебе не в COM-овских сапожнищах завалиться в дом и забрать своими грязными ручонками всё, что надо.

(5) Не вижу проблемы взять их код и переписать на http-сервис, который опубликовать в одной из баз
А другая база будет его дергать, получать данные и выводить сводный отчет

А OData не осилить - там документации на 5 страниц

(5) Да там осваивать толком нечего, особенно, если часто с различными API работаешь. Гайдов как рзвернуть http/web сервисы - вагон и маленькая тележка. Делаешь из одной базы http запрос у другой, та в ответе выплевывает json/xml файл с данными. Его читаешь в таблицу и пихаешь в отчет)

Можно так же таблицы создать для кэширования запросов, чтобы по 100500 раз одно и тоже не запрашивать. И уже по этим таблицам строить отчеты. Если же кэш протух, то делается новый запрос и обновляются данные.

(0) ODATA ёпта, если своё лень рисовать?

https://infostart.ru/1c/articles/1570140/
https://its.1c.ru/db/edtdoc/content/10382/hdoc

(12) Если данные получаются сложным путем (например из соединения множества таблиц с кучей параметров и с динамических изменением текста запроса), то проще все же свой сервис поднять. На стороне приемника сформировать этот сложный запрос с полученными параметрами и вернуть результат в источник.

(13) опередил
только хотел написать что odata не оптимально в сложных случаях
хотя и универсально

(13) если данные получаются сложным путём - проще допилить базу напильником и на стороне базы сложный путь сложить в виде готовых данных в добавленные регистры, например

и уже получать готовое. сложный путь повесить на фоновые задания

COM конечно гадость, но альтернативы ничуть не лучше. Вообще, нормальной нативной интеграции в 1с нет. Только через костыли той или иной степени кривости.

(16) чем вам http сервис не устраивает? Таким макаром все крупняки работают. Поднимают свою API и по ней обмениваются данными.

Т.е. перспективы дулей и полгода на разбор косяков вас не пугает?
Особенно весело когда валюта руб задвоена

(17) Это тоже костыль, нужно поднимать веб-сервер, публиковать там соответствующие компоненты и т.д. Кроме того, база-сервер должна быть соответственно доработана. А так, чтобы из одной типовой базы внешней обработкой подключиться к другой типовой базе, такой интеграции никто не дает, кроме COM, который кривой по дизайну изначально, из-за того что он завязан на микрософтовские типы данных, которые не идеально сочетаются с одинесовскими.

(19) Проблема не столько в костылях сколько в инвалидах.
Если код нормально написан (не лапша с дерганием через COM много раз) то он легко ложится на http-сервисы.

Проблема в том что обычно лапша и говнокод, который надо полностью переписывать логику работы для отказа от com-соединения.

(19) "Кроме того, база-сервер должна быть соответственно доработана" - так в вашем случае, нужно на стороне источника дорабатывать, чтобы описать какие данные получить от приемника. Тут же вы на приемнике пишите, какие данные отдать при запросе. Причем сервис может быть легко поднять в расширении и оперативно дорабатываться, как и внешняя обработка.

Если вы пишите про костыли в плане доп движений для поднятия самого сервиса, так на ком они ни чуть не меньше, почитайте сколько тут было веток про ошибки класса и т.д. при подключении ком)

(22) так ты не путай знакомый костыль с незнакомыми инвалидными колясками...

(17) "Чем веб-сервис не устраивает"

У меня около 40 баз клиентов. Базы чужие, при необходимости отдаем клиентам (когда завершаем договор).

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

И так да, я чайник. Не знаю, можно ли через http-сервис сделать то, что мне надо. наверное, нужно много учиться, но пока что все и так работает.

(23) Да я что с теми, что с другими обменами "собаку съесть" успел)

(24) Так ведь можно рег задание через внешнюю обработку прикрутить, которая раз в квартал будет вам ошибки по отчетам рассылать с указанием имени базы)

(26) Рег задание надо делать в КАЖДОЙ базе. Базы чужие. Снимать с поддержки не будем, накатывать расширения на каждую тоже.

Но все эти детали неважны. Важно - за чей счет банкет.
Устаревшая ком-технология в наших условиях позволяет решать эту проблему максимально дешево и сердито. Есть что-то типа центральной базы, которая последовательно открывает по кому базы клиентов, запускает в них проверочные отчеты, собирает результаты и формирует сводный отчет по выявленным проблемам.

Да, устаревшее, да, тру-программисты говорят свое "фи", но мне, извините, как-то пофиг. Просто в разработке, дешево для нас и клиентов, масштабировать на другие компы/сети не надо, работает надежно.

Я это все к тому, что инструмент должен подбираться по задаче. А стремиться к новым технологиям надо там, где это разумно и окупается.

(3) com конечно отвратительно. но как по другому с экселем взаимодействовать, например? А таких задач вагон и маленькая тележка.

Вот сейчас, например, натравил эту ком-технологию на 40 баз, проверил паспортные данные в каждой. Вижу, что неактуальных паспортных данных нет (а проверяю по базам ФНС и МВД). Значит. можно сдавать отчет РСВ и быть уверенным, что личные данные сотрудников достоверные.

А вот в прошлом квартале  нашел человек 10 тех у кого 20/45 лет, а паспорта новые не принесли.

Да вот было бы в 1с нативное взаимодействие, через собственную объектную модель, не используя корявый COM, было бы круто. Но не осилили, поэтому и предлагают прыгать на костылях в виде обменов через файлики или http, с обязательной сериализацией данных и программной поддержкой с обеих сторон обмена.

(29) внешняя обработка и запуск роботов аля тонкий клиент
это намного универсальней же да?
и ничуть не сложней делать

(30) не надо
уже костыльный ВИД прикрутили на кой то хрен

ты предлагаешь нечто подобное

(32) Внешние источники данных это вообще другое. Это тупо доступ к табличкам. А я предлагаю полноценный объектный доступ, из одной базы к другой. Но это намного сложнее, на порядки.

(33) Если не смогли реализовать то что проще
С чего взял что смогут то что сложней на порядки?

(28) Новый табличный документ умеет с ним работать. Xlsx - это просто архив xml, который, при желании читается.

(27) нельзя ту часть, что за ком отвечает, вынести на клиента?

(35) табдок не полнофункционален относительно excel'я
и да мне тоже странно что MS еще не сваял http-сервисы для своего MS Office встроенные

(27) "Снимать с поддержки не будем, накатывать расширения на каждую тоже." - открою вам секрет. Можно внешнюю обработку запускать как регламентное задание без изменения конфигурации и накатывания расширений. Типовые конфигурации на управляемых формах это умеют из коробки.

(38) а можно базу опубликовать на веб-сервере так чтобы внешняя обработка вызывалась?
без использования расширений, с ними то понятно как и программно их подключать и публиковать

(38) Спасибо, это я не знал - не разбирался, может потому что пока такое не надо.

Да мне и не надо регламентное задание. Мне нужно сделать проверку в нужный мне момент.

(39) А есть еще и базовые версии баз клиентов )) какие уж там расширения..

(39) А в чем проблема? Думаю, что можно, хоть и не тестил. По факту, это всего лишь ДД обработки которые хранятся в хранилище значений в справочнике дополнительных обработок. При запросе получаешь эти ДД и создаешь обработку и выполняешь ее.

(40) Тогда, как вариант это ODATA. Все базы развернутые публикуют этот протокол. А дальше вы спокойно обращаетесь к нужным табличкам и получаете данные.

(43) Каждую надо публиковать. Каждую! А я слишком ленив )

(41) А в базовых работает com-сервер?

(44) Программно же можно!

(42) Ну сделать универсальное расширение для вызова внешних обработок, вероятно можно
Как без снятия с ключика и без расширений?

(45) Отличный вопрос.. прошерстил список баз, как раз сейчас такой нет. Так что проверить не могу, но держу в голове, что теоретически принести могут.

(45)+ Речь не про базовую конфу на полной платформе - что спорный момент в плане нарушений

(46) Помилуйте,я  всего лишь тупой 1сник )) Ну а если серьезно, не учился это делать, так как пока что не было необходимости. По ком получается просто и сердито.

(48) Если на полной платформе с обычным ключиком запустите то пашет, проверено

(49) Открывал базу бухгалтерии на полной, орала, что нелицензионное использование. Было.

(0) я сделал через веб-сервис:  отдаешь сериализованную СКД схему (с отборами и параметрами в т.ч.) в другую базу, а в ответ получаешь сериализованную ТЗ
плюс для того, чтобы еще и RLS отрабатывал как надо во второй базе - подменял текущего пользователя в параметрах сеанса

(50) Т.е. у вас там нет плана B ?

(0) плюс есть же механизм копий баз

(52) Ааа это встроенная проверка лицензионности, она отключается при желании что тоже незаконно

(54) Нет. Сломаться может при уходе с винды. А что ком отключат - так это вряд ли, 1с сохраняет совместимость с прошлыми платформами.

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

(58) Так автоматизируйте уже вот это "будем открывать каждую вручную и запускать проверочный отчет"
Заранее.

(59) За это никто не заплатит походу)

(59) Прекрасное предложение, я двумя руками за. Одно не пойму - за чей счет банкет ))

(60) (61) А хотя бы руководство то в курсе?
А то у ТС в (0) вероятно были не в курсе ))

(35) xlsm - уже не прочитается табличным документом. да и тяжелые файлы им тоже не откроются. по второй части - наверно хотелось бы какое-то апи, если уж ком модель объявлена deprecated

(63) Лучше вообще стараться от эксель отказываться. Любой автоматический обмен с крупными системами реализован по средствам API через xml/json. Никто спецом файлики экселя не шлет. Завтра вам придется работать с линуксом, как вы там собираетесь майкрософтные файлы считать? Если уж делать грамотный обмен, то через универсальные протоколы.

Файлы xlsm могут быть сконвертированы в xlsx и далее уже стандартно прочитаны. Все равно, вы вряд ли макросы сможете в 1с использовать.

(0) Сначала надо ответить на такие вопросы.

1. Базы идентичные по конфе?
2. Что за 2 базы одна истрая другая акутальна или обе рабоче но разных фирм или ТОО?
3. Каков объем этих баз? За какой период*
4 Сколько юзеров хоят в эти базы?
5. Какой документооброт в каждой базе?

(64) речь не про обмен с другими информационными системами. С экселем работают практически все. и очень часто возникают задачи забрать что-то из него, или выгрузить в файл с макросами с определенным форматом. В парадигме "com использовать плохо" другого варианта нет. или плохо или никак.

(65) это да. но кто будет конвертировать: человек или машина? Если машина - это опять таки работа через com. а если человек - почему он должен заниматься такой тупой работой?

(68) Пора вырастать в больших дядек и самим дикторвать условия, чтобы остальные под вас подстраивались) Хотите эксель? Пожалуйста, вот вам формат единый, по этому шаблону загружайте данные. Хотите API, вот вам сервис пожалуйста. А не так, что все шлют как попало)

*диктовать

(62) Я и сам своего рода руководство. Ну а те, кто выше положением - поддерживают. Нужно вложить больше денег, чтобы получить тот же результат. И зачем?

(67) >часто возникают задачи забрать что-то из него, или выгрузить в файл с макросами с определенным форматом
Прекрасно выгружаю, переименуйте файл в zip, откройте и увидите обычные xml. Разобраться в структуре займет время, однако сохранение без COM на больших файлах работает раз в 30 быстрее.

(72) Получается так же работает xlsm как и xlsx все тот же архив с xml.

(0) вроде спрашивали уже.. Так нельзя что ли с клиента на Винде к базе подключиться?

(72) это понятно, что всё можно руками распарсить и назад собрать в xml. А раньше игрушки писали на ассемблерах. Только это куча человеко-часов, потраченных просто так ввиду того, что не предложено альтернативы com

(75) Если нужно только прочитать, то без проблем. Пишется разово обработка, которая по нужным папкам из архива данные собирает. Далее данные парсятся типовыми инструментами 1с и собираются в таблицу.
А вот если вам нужно получить на выходе excel файл с финдиплюшками, блокировками ячеек и прочими ништяками - то да, придется ковырять api экселя.