Добрый день, сообщество.
Вопрос такой...
Есть рабочая функция подключения (она работает)


    Сервер = "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 со значением Константы, содержащей имя сервера и, если значения различаются сделать переподключение.
Но нет цели менять значение Константы. Нужно понять "на лету", что текущее подключение не актуально и следует переподключиться...
???
Заранее спасибо

Много букв

(1) Я ж заранее благодарю )))))

(0) ты хочешь хранить подключение между серверными вызовами?

(3) ну... это уже так реализовано

(3) но есть проблема с временной недоступностью основного сервера

(0) есть идея сделать простой пробный запрос к sql-объекту [server].[база1] и если вернет ошибку, то - переподключиться
Но возможно есть более красивый вариант?!

up :(

(6)Думаю, нет более красивого

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

(8) (9) и на том спасибо

нагуглила это
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 Тогда
        //процесс переподключения
    КонецЕсли;

Пишиье, если найдутся еще решения...

(11) проверять "ONLINE" - ненадежно
причины для "отвалилось" могут быть разные
например права отняли или перевели базу в синглюзер

+ кроме того, если сервер не доступен, то и databases, конечно - тоже

поддержу (9)
не нужно хранить cnn, нужно переподключаться
у тому же ADODB умеет пулить коннекты

Шел 2018 год. До сих пор из 1С подключались к внешним базам по ADO.

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

А из 1С тупо использовать http и прочие веб-сервисы для подключения/получения данных?

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

(15) кагбе ADO и есть независимый от 1С внешний сервис.

(16) Это его проблемы

(17) COM/OLE (ActiveX) это устаревшая технология (сказали сами в MS) поддерживаемая только из совместимости древнего софта.
Каким местом будем по адо подключаться если сервер 1С на линуксе или в облаке?

(18) "Это его проблемы" ну он и будет подключаться тем же ADO
В итоге получиться только еще одна прокладка
Я не оспариваю, иногда нужна и такая прокладка, все от задачи и контекста зависит.

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

(19) Не обязательно использовать ADO есть разные способы подключения https://docs.microsoft.com/ru-ru/sql/connect/sql-connection-libraries?view=sql-server-2017

Пример такого сервиса обертки
https://www.red-gate.com/simple-talk/blogs/setting-up-a-simple-rest-interface-with-sql-server/
https://medium.com/voobans-tech-stories/how-to-quickly-create-a-simple-rest-api-for-sql-server-database-7ddb595f751a

(20) У вас какая версия 1С?
Про http://v8.1c.ru/overview/Term_000000795.htm в курсе?

(9) (14) это, конечно, да...
но при использовании темпоральных таблиц, другое подключение их просто не увидит (если это не глобальные временные таблицы, а они не глобальные)
приходится весь многоуровневый алгоритм отчета выполнять в одном подключении

(22) предприятие нетиповое 8.3.12.1529

(22) в курсе, но два источника в одном запросе почему-то не прокатило

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

а в данном случае мне нужны источники как sql server, так и oracle

(25) Вы издеваетесь?

Делайте отдельные запросы к разным источникам, затем соединяйте через ВТ в отдельном запросе.

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

(26) не издеваюсь)) рассуждаю...

Если данных много и запрос делаются долго то я бы вынес все нафик извне из 1С.

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

(29) такое решение обсуждается... ждемс

(0) Чтение любой константы в источнике не подойдет?

(31) а это не 1с база.

(32) это не база, это полигон отчетов на платформе 1С, сформированных из разных источников (((( грустно

(31) про константы не поняла... если через одну константу подключения нет, то пытаемся через другую

с разными  sql  лично я за вебсервисы и всю логику туда сложить, хотя если объемы большие - 1с может подавиться, лучше уж тогда view сделать или stored procedure

я как-то протупила слегка...
в (11) проверка доступности БД на условном сервере server, критикуют, но как вариант...
Но можно же проверить в любом месте любого отчета само подключение, запросив SQL.State()

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

...

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

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