Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

"На лету" проверить актуальность COM-подключения (adodb)

"На лету" проверить актуальность COM-подключения (adodb)
Я
   НеПридумалаНик
 
30.01.19 - 12:07
Добрый день, сообщество.
Вопрос такой...
Есть рабочая функция подключения (она работает)

    Сервер = "server";//значения берутся из констант, их две: основной и резервный сервера

    БД = "база1";
    
    cnn = Новый COMОбъект("ADODB.Connection");
    cnn.ConnectionTimeOut = 600;
    cnn.CommandTimeOut    = 0;
    cnn.connectionString  = "SERVER=" + Сервер + "; Database=" + БД + "; DRIVER=SQL Server; UID=user1; PWD=parolNNN;";
    cnn.CursorLocation    = 3;

    cnn.Open();
    if cnn.State()=0 then Возврат cnn;
    else Возврат 0;
    endif;


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

Задача такая: нужно оперативно, например, при нажатии условной кнопки "Рассчитать", проверить сначала актуальность текущего подключения и, если оно "отвалилось", подключиться к резервному серверу к базе-реплике, [serverNNN].[база1]. И далее, когда восстановится доступ к [server].[база1] переподключиться назад...

Можно сравнить текущий сервер подлючения cnn.Properties("Server Name").Value со значением Константы, содержащей имя сервера и, если значения различаются сделать переподключение.
Но нет цели менять значение Константы. Нужно понять "на лету", что текущее подключение не актуально и следует переподключиться...
???
Заранее спасибо
 
 
   Cyberhawk
 
1 - 30.01.19 - 12:09
Много букв
   НеПридумалаНик
 
2 - 30.01.19 - 12:10
(1) Я ж заранее благодарю )))))
   asady
 
3 - 30.01.19 - 12:12
(0) ты хочешь хранить подключение между серверными вызовами?
   НеПридумалаНик
 
4 - 30.01.19 - 12:13
(3) ну... это уже так реализовано
   НеПридумалаНик
 
5 - 30.01.19 - 12:14
(3) но есть проблема с временной недоступностью основного сервера
   НеПридумалаНик
 
6 - 30.01.19 - 12:20
(0) есть идея сделать простой пробный запрос к sql-объекту [server].[база1] и если вернет ошибку, то - переподключиться
Но возможно есть более красивый вариант?!
   НеПридумалаНик
 
7 - 30.01.19 - 12:35
up :(
   vis_tmp
 
8 - 30.01.19 - 12:41
(6)Думаю, нет более красивого
   ADirks
 
9 - 30.01.19 - 12:46
(0) Если рассчеты относительно трудоёмкие (относительно времени подключения), то лучше каждый раз заново подключаться.
   НеПридумалаНик
 
10 - 30.01.19 - 12:54
(8) (9) и на том спасибо
 
 Рекламное место пустует
   НеПридумалаНик
 
11 - 30.01.19 - 13:18
нагуглила это
https://docs.microsoft.com/ru-ru/sql/relational-databases/databases/database-states?view=sql-server-2017

использовала так:

    txt = "SELECT t.state_desc FROM sys.databases t WHERE t.name = 'база1'";
    R = Новый COMОбъект("ADODB.Recordset");
    R = SQL.Execute(txt);
    Переподключиться = 0;
    Если НЕ (СокрЛП(R.Fields("state_desc").Value) = "ONLINE") Тогда Переподключиться = 1; КонецЕсли;
    R.Close();
    
    Если Переподключиться = 1 Тогда 
        //процесс переподключения

    КонецЕсли;

Пишиье, если найдутся еще решения...
   trad
 
12 - 30.01.19 - 13:35
(11) проверять "ONLINE" - ненадежно
причины для "отвалилось" могут быть разные
например права отняли или перевели базу в синглюзер
   trad
 
13 - 30.01.19 - 13:37
+ кроме того, если сервер не доступен, то и databases, конечно - тоже
   trad
 
14 - 30.01.19 - 13:40
поддержу (9)
не нужно хранить cnn, нужно переподключаться
у тому же ADODB умеет пулить коннекты
   Garykom
 
15 - 30.01.19 - 13:43
Шел 2018 год. До сих пор из 1С подключались к внешним базам по ADO.

Вот почему нельзя поднять/наваять внешний сервис с этими внешними базами, независимый от 1С и наваянный на чем угодно?

А из 1С тупо использовать http и прочие веб-сервисы для подключения/получения данных?
   trad
 
16 - 30.01.19 - 13:56
(15) а этот "внешний сервис" как будет лазать в базу?
   ADirks
 
17 - 30.01.19 - 14:00
(15) кагбе ADO и есть независимый от 1С внешний сервис.
   Garykom
 
18 - 30.01.19 - 14:05
(16) Это его проблемы

(17) COM/OLE (ActiveX) это устаревшая технология (сказали сами в MS) поддерживаемая только из совместимости древнего софта.
Каким местом будем по адо подключаться если сервер 1С на линуксе или в облаке?
   trad
 
19 - 30.01.19 - 14:11
(18) "Это его проблемы" ну он и будет подключаться тем же ADO
В итоге получиться только еще одна прокладка
Я не оспариваю, иногда нужна и такая прокладка, все от задачи и контекста зависит.
   НеПридумалаНик
 
20 - 30.01.19 - 14:18
(15) ну, возможно потому, что бывают необходимы два внешних соединения, а в одном запросе нельзя выполнить обращение к двум внешним соединениям, насколько мне известно
   Garykom
 
21 - 30.01.19 - 14:20
   Garykom
 
22 - 30.01.19 - 14:21
(20) У вас какая версия 1С?
Про http://v8.1c.ru/overview/Term_000000795.htm в курсе?
   НеПридумалаНик
 
23 - 30.01.19 - 14:22
(9) (14) это, конечно, да...
но при использовании темпоральных таблиц, другое подключение их просто не увидит (если это не глобальные временные таблицы, а они не глобальные)
приходится весь многоуровневый алгоритм отчета выполнять в одном подключении
   НеПридумалаНик
 
24 - 30.01.19 - 14:24
(22) предприятие нетиповое 8.3.12.1529
   НеПридумалаНик
 
25 - 30.01.19 - 14:32
(22) в курсе, но два источника в одном запросе почему-то не прокатило

      |ИЗ
      |ВнешнийИсточникДанных_1.Тест1.Таблица.dbo_table КАК dbo1
      |ЛЕВОЕ СОЕДИНЕНИЕ 
      |ВнешнийИсточникДанных_2.Тест1.Таблица.dbo_table КАК dbo2
      |ПО Какое_то_соединение

а в данном случае мне нужны источники как sql server, так и oracle
   Garykom
 
26 - 30.01.19 - 14:33
(25) Вы издеваетесь?

Делайте отдельные запросы к разным источникам, затем соединяйте через ВТ в отдельном запросе.
   НеПридумалаНик
 
27 - 30.01.19 - 14:34
(12) это аварийные причины, права тоже не меняются, есть вполне плановые причины
Но не спорю, для общих целей, возможно, такой приём окажется не стабильным
   НеПридумалаНик
 
28 - 30.01.19 - 14:35
(26) не издеваюсь)) рассуждаю...
   Garykom
 
29 - 30.01.19 - 14:37
Если данных много и запрос делаются долго то я бы вынес все нафик извне из 1С.

В одну из баз mssql или oracle, причем данные из второй и из 1С туда бы постоянно переливались и в одной базе все формировалось для показа готового отчета неважно где, можно и в 1С.
   НеПридумалаНик
 
30 - 30.01.19 - 14:39
(29) такое решение обсуждается... ждемс
   stix2010
 
31 - 30.01.19 - 14:44
(0) Чтение любой константы в источнике не подойдет?
   stix2010
 
32 - 30.01.19 - 14:47
(31) а это не 1с база.
   НеПридумалаНик
 
33 - 30.01.19 - 14:50
(32) это не база, это полигон отчетов на платформе 1С, сформированных из разных источников (((( грустно

(31) про константы не поняла... если через одну константу подключения нет, то пытаемся через другую
 
 
   stix2010
 
34 - 30.01.19 - 15:00
с разными  sql  лично я за вебсервисы и всю логику туда сложить, хотя если объемы большие - 1с может подавиться, лучше уж тогда view сделать или stored procedure
   НеПридумалаНик
 
35 - 30.01.19 - 15:26
я как-то протупила слегка...
в (11) проверка доступности БД на условном сервере server, критикуют, но как вариант...
Но можно же проверить в любом месте любого отчета само подключение, запросив SQL.State()

Процедура ПередОткрытием(Отказ, СтандартнаяОбработка)
    SQL = Подключение();
КонецПроцедуры

...

Процедура Рассчитать()
    Если SQL.State() = 0 Тогда 
        //процесс переподключения

    КонецЕсли;
    ...
КонецПроцедуры

   Сияющий в темноте
 
36 - 30.01.19 - 16:04
State станет в ноль,если явно отключили,если дропнули подключение,то State станет 0 после вашей неудачной попытки что то выполнить.
Адо плоха тем,что числовые данные вываливает криво,т.к.они в 1с через Double переползают со всеми вытекающими.
опять же,массивы байт куда девать?


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