Задался вопросом - все работает. Но бывает что нужно обновить данные из другой БД.
В обычных формах этот вопрос легко решался.
А как и куда лучше/правильнее поместить КомКоннект?
Необходимо чтобы в то время, пока форма УФ открыта, не создавать каждый раз коннект.

ХЗ, например
Или общий модуль с кешированием значений

(1) Коннект сериализуется? Как его туда поместить?

(2) В ХЗ на сервере вроде хранится. Правда, не долго.

(3) Имеется ввиду временное хранилище?

(4) Ну да... )))

Апну что-ли.
Может есть какое-то еще решение.

Ну сделай неопределенного типа реквизит формы и попробуй в него и создавать сразу коннектор

&НаКлиенте
Перем КомКоннектор1;

2(3)Почему не долго? Пока форма открыта. Или в том плане что сам КомКоннектор может скиснуть? Ну тогда нужно периодически его дергать

(7) лишнее, достаточно переменной как в (8) она не передаётся на сервер с контекстом и не обнуляется между серверными вызовами, и живёт пока есть форма. Наверно, придётся написать код закрытия коннекта в ПриЗакрытии

(9) думается, что гемора с временным хранилищем побольше чем с локальной переменной (как минимум записать/прочитать). Использовать временное хранилище имеет смысл если нужно передавать коннектор между формами, даже нагляднее получится, чем с глобальной экспортной переменной.

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

(11) Можно поподробнее?
В общем модуле нельзя использовать переменные.
Поэтому коннект каждый раз будет создаваться и возвращаться.
Или в какой-то момент будет возвращаться кеш?
Чем это отличается от использования кеша Обработки, Отчета?

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

(10) ну и зачем переменная на клиенте нужна, все действия как правило на сервере выполняются?

Речь конечно же о сервере.

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

(16) Допустим класс КомОбъект действительно так написан, что может быть сериализован и помещен в кеш.

Но речь идет о внешнем отчете и вносить изменения в типовую конфигурацию не хочется.

(17) пользуйтесь вебсервисами уже. Нафига вам этот коннект сдался?

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

(16)+ далее, при если произойдет отказ сервера кластера на котором работал сеанс, сеанс будет перемещен на другой сервер в кластере, а эта функция (при ее вызове), снова отработает полностью. Для этого все и делалось.

(17)нет, он не написан так, он не сериализуется, но это не значит, что он не может быть помещен в кеш.

Кеш, это память а не диск, а вот хранилище значений это память, но обязательно сериализуемая для перемещения сеанса на другой сервер при отказе.

(14) Всё зависит от задачи, данные подготавливаются на сервере, а передаются через коннектор и наоборот.
Пример, как к файловой БД с сервера подключишься, если на сервере не установлен клиент и доступ к ней есть только у локального пользователя?

(11) Есть недостаток - если понадобится 2 коннектора (для второго вызова вернётся Коннектор1), и после закрытия коннектора - не факт, что не получишь "мёртвый" коннектор из кеша. Вся проблема в том, что рулит жизнью кеша сама платформа, а не программер и когда она решит передёрнуть коннектор не известно.

21+ возможно, что про повторно возвращаемые значения у меня несколько гнутое представление. Но ещё со студенчества помню "В ответственной системе функции с кешированием возвращаемого значения опасны из-за невозможности определения момента обновления кеша"

(17)>>Но речь идет о внешнем отчете и вносить изменения в типовую конфигурацию не хочется.

А это от того, что писатели платформы далеки от того, для чего они это пишут.

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

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

(22)а с недостаточным управлением кешем, это да у платформы проблемы, нет программной частичной очистки, эта та же проблема, что описана в (23). Им "по барабану".

(0) если речь о разовом вызове в пределах какой то процедуры, то я делал так

Соединение = ПолучитьСоединение();
ПеренестиДокументыПоступления(Соединение);
ПеренестиДокументыРеализации(Соединение);

в них могло быть что-то типа

Процедура ПеренестиДокументыПоступления(Соединение)

Для Каждого // тут цикл по контрагентам
Контрагент = НайтиСоздатьКонтрагента(ТекКонтрагент, Соединение);
КонецЦикла;

КонецПроцедуры

(0) Никак.
В любом случае будет создаваться каждый раз новое соединение, иначе будет постоянно зависать.
Размещай в серверной части

2(10) Временное Хранилище нужно чтобы сохранять комконнектор между серверными вызовами, чтобы каждый раз не инициализировать его.
Хранить можно кстати в параметре сеанса.

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

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

Позже проверю другие варианты, включая кеш.
Ситуация с ОбщемМодулем тоже интересная. Большой минус - невозможно реализовать во внешней обработке.

(30) что за сатанизм?

Если требуется регулярное получение данных из другой БД, то на лицо необходимость в нормальном обмене.

(31) Отчёт по складам, продажам, с привязкой к кадровым данным.
склады и продажи - в торговле, кадровые данные - в зупе.

(32) Так, и в чем проблема засосать в торговлю кадровые данные?

(33) Да к то ж тебе даст в базу, с которой работает 500 человек, лить такие данные, как номер паспорта или реальный оклад?

(34) Вообще не вижу проблемы сейчас.
Давно с 1С работаешь?

(35) Нет. Всего 15 лет.

(34) а они там надо? и прямо через комконнектор и в реальном времени? такие данные не меняются каждые 5 мин, тем более, что достаточно РС со связкой Пользователь Склада = Физ.лицо (или сотрудник) из ЗУПа, на который можно опереться при передаче данных в ЗУП (в ситуации: "насчитали такому продавцу столько премии" вместо ссылки из "Склада" выгружаем, то чему она соответствует в ЗУП)

(37) Нет. Никто не позволит лить данные кадрового учёта в торговлю.
Им там нечего делать.

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

Если ты этот отчет формируешь в УТ - то считай данные есть в УТ.

(39) Вот именно. А программист иногда учитывает ещё и объёмы данных и общую нагрузку на систему.
Хотя, может, это только я один такой уникум.

(40) Да однозначно уникум. Использовать комконнектор и думать о нагрузке... сочетание не сочетаемого.

(41) Да ладно, какая нагрузка от него? А вот лишние данные, если они не нужны в базе, на самом деле не нужны

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

(43) Раз в месяц лить обмен через ком-коннектор

А че насчет веб-сервисов?

(38) вот и я про то же, не надо гонять данные между системами. Лишнее это.
(40) тут, конечно, локальному программеру виднее что менее затратно по ресурсам: через коннект всасывать данные для неких манипуляций (с риском что их увидит тот кому не положено) или сохранить ссылки для выгрузки (обмена) данных. Данные хранятся в своей песочнице (с соответствующим доступом), а обмен их актуализирует (с нужной периодичностью)
(42) а они лишние? - значит они в БД не надо и без коннектора и с ним.
(43) в твоём варианте: коннектор понадобится при каждом формировании, например, отчёта
(44) логично, но через файл - универсальнее (всё зависит от построенной системы)

(44) Ещё раз - зачем все эти данные в торговле?
И место занимают, и безопасность снижается.

(46) отчёт формируется один раз в месяц.

(45) нужен Веб-сервер и обеспечение его безопасности
(47) да не надо их хранить целиком, и показывать в отчёте то же не сильно нужно. Для Кадров - ЗУП, для информации - Торговля. Ситуация формирования неких отчётов используя 2 базы крайне ненормальная. Тогда уж лучше сделать управленческую БД с соответствующим доступом и загрузкой нужной информации.
(48) и? Есть гарантия что, например, начальник не захочет сформировать его по желанию левой пятки?

(49) Отчёт не для начальника.
Да и вообще, давайте абстрагируемся от зупа.
Есть совершенно сторонняя БД (не 1с). Данные из неё нужны очень постоянно (там ведётся учёт производства).
Как будем обходиться без коннектора?

Ну если Вам интересно - БП и ЗУП. Из ЗУП нужны среднесписочные численности по подразделениям.

(50) Да никак.
А вот более специфичная ситуация. Есть WMS, есть 1С, надо регулярно сравнить между ними остатки. И показывать расхождение.

Господа, если есть внешняя БД, то ADODB в помощь.

А там уже на ваше усмотрение, сохранять данные или нет.

(50) имея структуру - Внешние данные или ADODB. Не хотим прямого подключения - обмен через файл.
Опять же - что нам в ней нужно? Объём выпуска, нормы выработки работников, отметки ОТК, этап тех.процесса?
Вот прямо все данные из оной БД нужны для отчёта в 1С? В такой постановке вопроса без конкретики по задаче и инфраструктуре - абстрактные рассуждения "Мне больше нравится (удобнее, менее затратно) ..."
(51) для чего? выгрузка для гос.отчётности, тем более бухи имеют доступ в обе конфигурации - один раз руками внесут.

(54) АДО давно перестала работать через COM?
"что нам в ней нужно" - отметки о продукции, вышедшей с линии. Отметки о загрузке станков. О их производительности. Об их поломках.

(54) Для более детальной расшифровки статей затрат "Оплата труда" и "Страховые взносы", включая в этой расшифровке и среднюю ЗП по подразделению.

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

(52) у WMS, обычно, есть некий интерфейс и смотря что он умеет на то и опираемся (возможно и через веб-интерфейс)
(55) так тебе виднее, что быстрее, что сохранить "для сверки", например, станок простаивал, отметка есть и сохранена в 1С, некто ушлый меняет его режим на "работал" и толку от оптимального хранения без дублирования?
(56) а зачем это формировать прямо из БП?
(57) в постановке задачи (50) - надо данные подключись, а не держи открытым коннект до посинения (может он и не понадобится)

(52) Внешние Источники

(58) Це не дублирование, а формирование документов по учёту производства.

(60) Вот! а как ты для них получишь информацию и насколько оптимально её вложишь в документы зависит от постановки задачи и возможностей производственной системы