Вход | Регистрация


1С:Предприятие :: 1С:Предприятие 8 общая

Постоянное подключение к внешней базе

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

Переменная глобального серверного модуля?
 
 
   Провинциальный 1сник
 
1 - 31.08.18 - 11:53
Красиво никак не получится. В управляемом приложении нет общих переменных в памяти. Каждый серверный вызов создает новый серверный контекст, ибо он может вообще оказаться не то что на другом рабочем процессе, а и вообще на другом физическом сервере.
   Провинциальный 1сник
 
2 - 31.08.18 - 11:55
Есть как вариант костыль через модуль с повторно возвращаемыми значениями. Но во-первых этот кэш протухает через 20 минут, а во-вторых опять же всё зависит от того, на какой рабочий процесс бросится вызов.
   Лефмихалыч
 
3 - 31.08.18 - 11:58
   akhamov
 
4 - 01.09.18 - 08:36
(3) не понимаю причем тут linked servers.
А по теме вообще печаль получается, если в рамках сеанса нельзя держать постоянный Коннект.
Значит придется заливать в базу 1с данные из внешнего источника...
   Cool_Profi
 
5 - 01.09.18 - 08:40
Я делал это чере модуль с повторными. Причём проверял, если соединение протухло, то переподключался.
Правда, это было ещё на 8.2, где объекты жили минут по 20. В 8.3 они живут по 2-3 минуты...
   akhamov
 
6 - 01.09.18 - 09:49
(5) дело в том что у тебя запросы будут раз 15-20 секунд и по идее оно не должно протухнуть, вопрос если будет новые серверный контекст, вот тут тогда да(
   Cool_Profi
 
7 - 01.09.18 - 09:54
(6) Оно тухло. Запросы шли не реже, чем раз в минуту (когда цех работал).
   Сергиус
 
8 - 01.09.18 - 11:18
(0)А в чем необходимость постоянно брать данные из сторонней базы? Точнее говоря, в чем тут проблема? Обычно так делается, для того, чтобы получать какие-то второстепенные, не очень важные доп.сведения..так тут и проблемы нет, небольшие задержки при новом подключении не будут сильно влиять на общую скорость работы. Если же у тебя заложено по логике, что из сторонней базы берутся важные данные и они нужны постоянно, то тут скорее надо думать об объединении данных 2-х баз в какую-то общую.
   МихаилМ
 
9 - 01.09.18 - 11:32
(0)
+(3) сделайте в базе 1с таблицы со структурой близкой
к таблицам бд мс скл . замените их на view. view настройте
на просмотр таблиц внешней бд.

также напишите ddl trigger для отмены реструктурицации таблиц , замененный представлениями.
   akhamov
 
10 - 01.09.18 - 12:02
(9) кстати как вариант можно рассмотреть. Спасибо. Про триггер против обновления нужно подумать будет.
 
 Рекламное место пустует
   Cool_Profi
 
11 - 01.09.18 - 13:10
(8) @Обычно так делается, для того, чтобы получать какие-то второстепенные, не очень важные доп.сведения.@

Покеазатели работы бригады и информация о выпущенной продукции - это второстепенная информация?
   Cyberhawk
 
12 - 01.09.18 - 13:42
Делаешь регулярный импорт сырых данных из ВИДа в инфобазу (регистры / справочники).
Работаешь только с инфобазой.
Профит.
   Cyberhawk
 
13 - 01.09.18 - 13:42
Но это конечно же если в ВИДе есть timestamp у каждой нужной таблицы, хранящий дату последнего изменения. Чтоб импортировать только измененные данные.
   Сергиус
 
14 - 01.09.18 - 14:44
(11)Сколько раз в день может понадобится такая информация?  Если раз-два(какой-ть отчет вывести к примеру), то и проблема со временем подключения к удаленной базе не критична. Если эти данные нужны многократно, то что мешает вводить их сразу в 1с(ведь они как-то вводятся же в ту базу)?
   Cool_Profi
 
15 - 01.09.18 - 15:02
(14) Ежеминутно, я написал. По факту выпуска продукции с линии должОн был создаваться документ выпуска, чтобы склад его увидел
   Cool_Profi
 
16 - 01.09.18 - 15:02
(14) "Если эти данные нужны многократно, то что мешает вводить их сразу в 1с(ведь они как-то вводятся же в ту базу)?"
То, что производственный контур писал их не в 1с, а в свою базу.
   Сергиус
 
17 - 01.09.18 - 16:15
(16)Производственный контур это что? Какое-то закрытое решение, работающее по принципу "что есть, то и используйте"?
   akhamov
 
18 - 01.09.18 - 19:36
(14)(17)
Есть производственный контур в виде ПО и конвейера которые пишут результат своей работы по каждому выпущенному продукту в свою базу mssql раз в 10-15 секунд, но дальше мне нужно забрать это в 1C ERP 2 по факту требования оператора (путем сканирования на мобильном рабочем месте) и обработать результат. Постоянный реконнект убьет всю скорость, а запись в бд 1с будет растить ее лог размер и порождать не нужные блокировки, хотя у меня по факту не будет грязного чтения, но будет плюс один сервис синхронизации..
   Cool_Profi
 
19 - 01.09.18 - 19:49
(17) Почти так. Внешняя база, которая ловила события с цеха. А мне их нужно было учитывать в 1с.
   Сергиус
 
20 - 02.09.18 - 00:28
(18)Тут в любом случае не будет оптимального решения.

Как часто надо предоставлять оператору эти сведения? Возможно стоит пожертвовать мгновенностью, и сделать какое-ть фоновое задание, которое раз в 30 минут(к примеру) будет тянуть данные из той базы.
   akhamov
 
21 - 02.09.18 - 08:26
(20) это хаотичный выпуск штрихкодированной продукции и сборка  по ящикам руками оператора через алгоритмы как раз уже со стороны ЕРП.

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

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

Либо да, заморачиваться с view и постоянный Коннект будет уже обеспечен со стороны mssql linked servers
   DmitrO
 
22 - 02.09.18 - 11:03
(0) не надо никаких линкед серверов и view
Надо функцию создающую подключение по ADODB разместить в модуле с повторно возвращаемым значениями на время сеанса.
Плюс даже по-умолчанию OLEDB провайдер соединения от одного процесса пулит, и параметры пулинга настраиваются.
Все будет хорошо.
   akhamov
 
23 - 02.09.18 - 11:26
(22) в том смысле что он не будет "прокисать" при таких запросах частых и не будет переброса на другой серверный сеанс? Почему? Я конечно буду пробовать, но все таки откуда такая теория?
Про настройку пулинга обязательно почитаю. Спасибо
   DmitrO
 
24 - 02.09.18 - 11:47
(23)А почему оно должно прокисать, кеширование в виде повторно возвращаемых для этого и придумано.

Ну какой, блин, другой серверный сеанс? У вас что, часто сеансы перепыгивают на другой рабочий процесс? Если это так то это не нормальное поведение для сервера 1С, это должно происходить только при отказах рабочего процесса.
   akhamov
 
25 - 02.09.18 - 12:14
(24) принято. спасибо. завтра буду тестировать
   Провинциальный 1сник
 
26 - 02.09.18 - 14:58
(24) "А почему оно должно прокисать, кеширование в виде повторно возвращаемых для этого и придумано. "
Это черный ящик, единственное что 1с гарантирует - что через 20 минут неактивности кэш протухает. Но он может протухнуть и раньше, если например сервер посчитает что ему мало памяти.
   sechs
 
27 - 02.09.18 - 15:06
(24) Это вообще-то происходит по усмотрению менеджера кластера, назначению функциональности и т.п. И это не просто нормальное, это расчетное и задокументированное поведение.
   akhamov
 
28 - 04.09.18 - 08:12
Попробовал через модуль с повторными значениям, вроде отлично работает, только в случае исключительных ситуаций конект рвется и приходится вызывать обновление кэширрванных значений, но это исключение и клиент вполне ждёт


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует