This is topic Выполнение SQL-запросов RTM в реальном времени in forum Мониторы Реального Времени / Real Time Monitors at Форум TRACE MODE: техническая поддержка.
Цитата из раздела хелпа "Выполнение SQL-запросов в реальном времени": "Если SQL-запрос по каким-либо причинам выполнить невозможно, то по истечении 600 секунд с момента инициализации запроса каналу CALL устанавливается признак аппаратной недостоверности." В действительности установки каналу вызывающему шаблон связи с БД признак аппаратной недостоверности не устанавливается, хотя судя по работе ODBC драйвера ч/з несколько десятков секунд где то около 20-30 RTM освобождает драйвер, но 4-й атрибут остаётся равным нулю. Всё бы ничего, только в реальных условиях невозможно отследить корректность работы с базой по этому каналу (который шаблон связи вызывает) и соответственно прекратить записывать во входное значение этого канала №запроса для чтения с базы информации. Там (в хелпе) есть ещё вот это:"Значение канала CALL задает номер выполняемого запроса (см. Создание SQL-запросов ). После отработки, значение канала автоматически сбрасывается в 0." На самом деле, даже если нет связи, реальное значение в ноль сбрасывается, по истечении вышеуказанного таймаута, не смотря на то что запрос фактически не отработан! Поэтому у Нас вопрос: Как отследить обрыв связи с БД, чтобы остановить опрос, т.к. при её отсутствии наблюдается периодическое подвисание РТМ с циклом равным циклу отработки канала выз-го шаблон св. с БД? Но так, чтоб это было более менее оперативно.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. 0 образуется в канале в момент отработки канала, а не запроса.
2. К сожалению, сейчас доступна только косвенная диагностика для запросов на чтение. В аттрибут I1 возвращается количество считанных строк. Если 0, то с некоторой вероятностью запрос не проходит, но существует также вероятность, что в базе просто нет таких записей.
3. Чтобы канал связи с БД не подвешивал систему, можно перевести его в поток Idle. Раньше так и было по умолчанию, сейчас он находится в основном потоке.
Posted by Grigorovskih (Участник № / Member № 1915) on :
К сожалению перевод в поток IDLE не решает полностью эту проблему, ведь программа которая "инициирует" (посылает во вх. значение канала связи с БД №запроса) запрос с периодом пересчёта канала, который вызывает её шаблон, продолжает это делать, не смотря на то что коннекта к базе нет, и в эти моменты происходит "замирание" всех элементов экрана на 5-10 секунд, а когда оператор управляет объектом это не шутки. Недавно у нас как раз была такая ситуация, и нам пришлось дать не мало объяснений по этому поводу. И всё же, не смотря на то что возможно у Вас нет в планах решение этой проблемы, мы убедительно просим занятся этой темой. Мы сейчас даже временно не можем застраховать себя на случай, когда вдруг такая ситуация повторится и что самое страшное, это то что оператор не знает о том что произошло зависание, и считает что процесс протекает в норме. Нам нужен какой либо признак по которому мы могли бы остановить отработку программы отрабатывающей запрос .
Posted by Grigorovskih (Участник № / Member № 1915) on :
Атрибут I1 - это атрибут под номером 91?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Да, именно он.
Posted by Dmitry.niimm (Участник № / Member № 3380) on :
И я свой пятачок суну...
В нашем проекте используется две базы данных: локальная на Firebird (основная) и сетевая на MSSQL.
Так как доступ к сетевой базе идет через модемную линию и периодически пропадает, то, дабы не подвешивать монитор, соответствующий канал запроса был вынесен в отдельный поток.
Вот только работать там он не желает: после подачи на вход номера запроса канал отрабатывает, т.е. аргументы канала изменяются в соответствии с принятыми данными и выставляется время изменения, но отработка не завершается (не сбрасываются в ноль ch.in и ch.r) и канал зависает. Дальнейшие попытки оживить канал путем пихания различных значений в разные атрибуты ни к чему не приводят.
Для проверки тот же самый канал, перемещенный в цикл calc, работает отлично, т.е. дело вовсе не в его кривой настройке.
Вариант "перенести в цикл idle" просьба не предлагать, т.к. это может привести к тормозам в работе с основной (локальной) базой при пропадании сети.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. Основная база у Вас находится в потоке Idle?
2. В какой отдельный поток Вы вынесли обмен с сетевой БД?
Posted by Dmitry.niimm (Участник № / Member № 3380) on :
1. Нет, пока что в основном - сбои по локальной базе маловероятны, а скорость важна. Но хотелось унести сетевой канал в отдельный поток, чтоб не тормозить то, что находится в idle (там работает пара обслуживающих каналов типа пересчета, очистки и статистики).
2. Указали "свой поток", номер 1. Кстати, аналогичная проблема была и при установке периода отработки канала 1 минута (другие варианты не пробовал).
Причем, что характерно, ситуация абсолютно повторяемая и не зависящая от базы данных, т.е. создал новый проект с одним шаблоном запроса к БД, расположенной на локальном компе под управлением Firebird и тремя абсолютно одинаковыми каналами Call.SQL. Единственная разница у каналов - периоды выполнения (1 calc, 1 минута и "свой поток"). Вариант с потоком Idle в тесте не использовался. Запуск осуществлялся вручную через окно просмотра каналов. Из трех каналов корректно работал только тот, что был в основном потоке, а два других зависали после первой отработки.
И, если можно, вопрос не в тему. Куда подевалась техподдержка в Киеве? Уже больше месяца не отвечает ни один телефон. На Вашем сайте изменений их реквизитов не обнаружено...
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
В 91-м атрибуте ничего не появляется, т.е. нуль! Хотя данные с базы RTM успешно получает и количество считанных строк ни как неможет быть равно 0. В чём могут быть причины?
Posted by Grigorovskih (Участник № / Member № 1915) on :
Уважаемые Господа!
С момента размещения вышеизложенного сообщения прошла неделя! Есть какие либо соображения по поводу отсутствия информации в 91-м атрибуте?
Posted by Grigorovskih (Участник № / Member № 1915) on :
Господа!
Может кто нибудь всё таки ответит на этот вопрос?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Проверил на двух разных БД (Access и MS SQL server). Все работает.
Posted by Grigorovskih (Участник № / Member № 1915) on :
Работать то работает...
Можно тестовый проектик, с любой табличкой БД, для примера, чтоб мы у себя смогли проверить и увидели что нибудь в 91-м атрибуте.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
![[Недоумение / Confused]](confused.gif)
.