Коллеги, добрый день.
Задача следующая:
Есть база с публикацией на веб сервер, с ней работают тонкие и веб клиенты.
Необходимо постоянно брать данные из внешней базы MSSQL.
Как лучше организовать подключение к базе?
Через внешние источники или через обычный ODBC объект?
И как правильно создать подключение к MSSQL чтобы оно постоянно висело подключенным хотя для каждого клиентского сеанса постоянно, а не подключаться \ отключаться для получения очередной порции данных.
Собственно как организовать keep alive для MSSQL сервера со стороны 1С?

Переменная глобального серверного модуля?

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

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

https://docs.microsoft.com/ru-ru/sql/relational-databases/linked-servers/create-linked-servers-sql-server-database-engine?view=sql-server-2017

оно?

(3) не понимаю причем тут linked servers.
А по теме вообще печаль получается, если в рамках сеанса нельзя держать постоянный Коннект.
Значит придется заливать в базу 1с данные из внешнего источника...

Я делал это чере модуль с повторными. Причём проверял, если соединение протухло, то переподключался.
Правда, это было ещё на 8.2, где объекты жили минут по 20. В 8.3 они живут по 2-3 минуты...

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

(6) Оно тухло. Запросы шли не реже, чем раз в минуту (когда цех работал).

(0)А в чем необходимость постоянно брать данные из сторонней базы? Точнее говоря, в чем тут проблема? Обычно так делается, для того, чтобы получать какие-то второстепенные, не очень важные доп.сведения..так тут и проблемы нет, небольшие задержки при новом подключении не будут сильно влиять на общую скорость работы. Если же у тебя заложено по логике, что из сторонней базы берутся важные данные и они нужны постоянно, то тут скорее надо думать об объединении данных 2-х баз в какую-то общую.

(0)
+(3) сделайте в базе 1с таблицы со структурой близкой
к таблицам бд мс скл . замените их на view. view настройте
на просмотр таблиц внешней бд.

также напишите ddl trigger для отмены реструктурицации таблиц , замененный представлениями.

(9) кстати как вариант можно рассмотреть. Спасибо. Про триггер против обновления нужно подумать будет.

(8) @Обычно так делается, для того, чтобы получать какие-то второстепенные, не очень важные доп.сведения.@

Покеазатели работы бригады и информация о выпущенной продукции - это второстепенная информация?

Делаешь регулярный импорт сырых данных из ВИДа в инфобазу (регистры / справочники).
Работаешь только с инфобазой.
Профит.

Но это конечно же если в ВИДе есть timestamp у каждой нужной таблицы, хранящий дату последнего изменения. Чтоб импортировать только измененные данные.

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

(14) Ежеминутно, я написал. По факту выпуска продукции с линии должОн был создаваться документ выпуска, чтобы склад его увидел

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

(16)Производственный контур это что? Какое-то закрытое решение, работающее по принципу "что есть, то и используйте"?

(14)(17)
Есть производственный контур в виде ПО и конвейера которые пишут результат своей работы по каждому выпущенному продукту в свою базу mssql раз в 10-15 секунд, но дальше мне нужно забрать это в 1C ERP 2 по факту требования оператора (путем сканирования на мобильном рабочем месте) и обработать результат. Постоянный реконнект убьет всю скорость, а запись в бд 1с будет растить ее лог размер и порождать не нужные блокировки, хотя у меня по факту не будет грязного чтения, но будет плюс один сервис синхронизации..

(17) Почти так. Внешняя база, которая ловила события с цеха. А мне их нужно было учитывать в 1с.

(18)Тут в любом случае не будет оптимального решения.

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

(20) это хаотичный выпуск штрихкодированной продукции и сборка  по ящикам руками оператора через алгоритмы как раз уже со стороны ЕРП.

Штрих-код наносит как раз система и параметры артикул, вес, размер, упаковка тут же пишет в базу mssql к которой я и организую доступ.

В общем либо базу и сервер 1с максимально "сближать" чтоб постоянный реконнект был быстрым либо навешивать некий сервис с постоянным коннектном в базу и интерфейсом для 1с Аля web или http сервисов.

Либо да, заморачиваться с view и постоянный Коннект будет уже обеспечен со стороны mssql linked servers

(0) не надо никаких линкед серверов и view
Надо функцию создающую подключение по ADODB разместить в модуле с повторно возвращаемым значениями на время сеанса.
Плюс даже по-умолчанию OLEDB провайдер соединения от одного процесса пулит, и параметры пулинга настраиваются.
Все будет хорошо.

(22) в том смысле что он не будет "прокисать" при таких запросах частых и не будет переброса на другой серверный сеанс? Почему? Я конечно буду пробовать, но все таки откуда такая теория?
Про настройку пулинга обязательно почитаю. Спасибо

(23)А почему оно должно прокисать, кеширование в виде повторно возвращаемых для этого и придумано.

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

(24) принято. спасибо. завтра буду тестировать

(24) "А почему оно должно прокисать, кеширование в виде повторно возвращаемых для этого и придумано. "
Это черный ящик, единственное что 1с гарантирует - что через 20 минут неактивности кэш протухает. Но он может протухнуть и раньше, если например сервер посчитает что ему мало памяти.

(24) Это вообще-то происходит по усмотрению менеджера кластера, назначению функциональности и т.п. И это не просто нормальное, это расчетное и задокументированное поведение.

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