|
"На лету" проверить актуальность COM-подключения (adodb) | ☑ | ||
---|---|---|---|---|
0
НеПридумалаНик
30.01.19
✎
12:07
|
Добрый день, сообщество.
Вопрос такой... Есть рабочая функция подключения (она работает)
Однако, если функция вернула 0, то предпринимается попытка подключения к резервному серверу (есть такие периоды, когда происходят какие-то работы с базой на основном сервере и она становится временно недоступной). И при первом подключении (например, при открытии отчета) это срабатывает, и подключение держится до закрытия отчета. Задача такая: нужно оперативно, например, при нажатии условной кнопки "Рассчитать", проверить сначала актуальность текущего подключения и, если оно "отвалилось", подключиться к резервному серверу к базе-реплике, [serverNNN].[база1]. И далее, когда восстановится доступ к [server].[база1] переподключиться назад... Можно сравнить текущий сервер подлючения cnn.Properties("Server Name").Value со значением Константы, содержащей имя сервера и, если значения различаются сделать переподключение. Но нет цели менять значение Константы. Нужно понять "на лету", что текущее подключение не актуально и следует переподключиться... ??? Заранее спасибо |
|||
1
Cyberhawk
30.01.19
✎
12:09
|
Много букв
|
|||
2
НеПридумалаНик
30.01.19
✎
12:10
|
(1) Я ж заранее благодарю )))))
|
|||
3
asady
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 :(
|
|||
8
vis_tmp
30.01.19
✎
12:41
|
(6)Думаю, нет более красивого
|
|||
9
ADirks
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 Тогда //процесс переподключения КонецЕсли; Пишиье, если найдутся еще решения... |
|||
12
trad
30.01.19
✎
13:35
|
(11) проверять "ONLINE" - ненадежно
причины для "отвалилось" могут быть разные например права отняли или перевели базу в синглюзер |
|||
13
trad
30.01.19
✎
13:37
|
+ кроме того, если сервер не доступен, то и databases, конечно - тоже
|
|||
14
trad
30.01.19
✎
13:40
|
поддержу (9)
не нужно хранить cnn, нужно переподключаться у тому же ADODB умеет пулить коннекты |
|||
15
Garykom
гуру
30.01.19
✎
13:43
|
Шел 2018 год. До сих пор из 1С подключались к внешним базам по ADO.
Вот почему нельзя поднять/наваять внешний сервис с этими внешними базами, независимый от 1С и наваянный на чем угодно? А из 1С тупо использовать http и прочие веб-сервисы для подключения/получения данных? |
|||
16
trad
30.01.19
✎
13:56
|
(15) а этот "внешний сервис" как будет лазать в базу?
|
|||
17
ADirks
30.01.19
✎
14:00
|
(15) кагбе ADO и есть независимый от 1С внешний сервис.
|
|||
18
Garykom
гуру
30.01.19
✎
14:05
|
(16) Это его проблемы
(17) COM/OLE (ActiveX) это устаревшая технология (сказали сами в MS) поддерживаемая только из совместимости древнего софта. Каким местом будем по адо подключаться если сервер 1С на линуксе или в облаке? |
|||
19
trad
30.01.19
✎
14:11
|
(18) "Это его проблемы" ну он и будет подключаться тем же ADO
В итоге получиться только еще одна прокладка Я не оспариваю, иногда нужна и такая прокладка, все от задачи и контекста зависит. |
|||
20
НеПридумалаНик
30.01.19
✎
14:18
|
(15) ну, возможно потому, что бывают необходимы два внешних соединения, а в одном запросе нельзя выполнить обращение к двум внешним соединениям, насколько мне известно
|
|||
21
Garykom
гуру
30.01.19
✎
14:20
|
(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 |
|||
22
Garykom
гуру
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 |
|||
26
Garykom
гуру
30.01.19
✎
14:33
|
(25) Вы издеваетесь?
Делайте отдельные запросы к разным источникам, затем соединяйте через ВТ в отдельном запросе. |
|||
27
НеПридумалаНик
30.01.19
✎
14:34
|
(12) это аварийные причины, права тоже не меняются, есть вполне плановые причины
Но не спорю, для общих целей, возможно, такой приём окажется не стабильным |
|||
28
НеПридумалаНик
30.01.19
✎
14:35
|
(26) не издеваюсь)) рассуждаю...
|
|||
29
Garykom
гуру
30.01.19
✎
14:37
|
Если данных много и запрос делаются долго то я бы вынес все нафик извне из 1С.
В одну из баз mssql или oracle, причем данные из второй и из 1С туда бы постоянно переливались и в одной базе все формировалось для показа готового отчета неважно где, можно и в 1С. |
|||
30
НеПридумалаНик
30.01.19
✎
14:39
|
(29) такое решение обсуждается... ждемс
|
|||
31
stix2010
30.01.19
✎
14:44
|
(0) Чтение любой константы в источнике не подойдет?
|
|||
32
stix2010
30.01.19
✎
14:47
|
(31) а это не 1с база.
|
|||
33
НеПридумалаНик
30.01.19
✎
14:50
|
(32) это не база, это полигон отчетов на платформе 1С, сформированных из разных источников (((( грустно
(31) про константы не поняла... если через одну константу подключения нет, то пытаемся через другую |
|||
34
stix2010
30.01.19
✎
15:00
|
с разными sql лично я за вебсервисы и всю логику туда сложить, хотя если объемы большие - 1с может подавиться, лучше уж тогда view сделать или stored procedure
|
|||
35
НеПридумалаНик
30.01.19
✎
15:26
|
я как-то протупила слегка...
в (11) проверка доступности БД на условном сервере server, критикуют, но как вариант... Но можно же проверить в любом месте любого отчета само подключение, запросив SQL.State() Процедура ПередОткрытием(Отказ, СтандартнаяОбработка)
|
|||
36
Сияющий в темноте
30.01.19
✎
16:04
|
State станет в ноль,если явно отключили,если дропнули подключение,то State станет 0 после вашей неудачной попытки что то выполнить.
Адо плоха тем,что числовые данные вываливает криво,т.к.они в 1с через Double переползают со всеми вытекающими. опять же,массивы байт куда девать? |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |