This is topic Проблемы ТМ v 6.05.1 при работе ч/з ODBC с БД in forum Работа с приложениями (ODBC-SQL/OPC/DDE) at Форум TRACE MODE: техническая поддержка.
Уважаемые Господа разработчики! Открываем новый топик, так как в топике "Настройка времени цикла монитора" раздела "Мониторы реального времени" тема сменилась на работу с SQL/ После продолжительных проверок выяснилось, что проекты работающие и скомпилированные в версии ТМ 6.05 не вызывают проблем при работе с ODBC драйвером ОС, при переходе в ТМ6.05.1 начинаются проблемы описанные в вышеуказанном топике, напомню: //Нами был обнаружен тот факт, что при включении обмена с БД канала CALL связанного с шаблоном и программы посылающей раз в 10 с. во входное значение этого канала номер запроса наблюдается периодическое многократное (на порядок!!!) превышение цикла монитором, что подтверждает скачкообразное, одновременно с CalculateCycle, возрастание IdleLoop. При чём это происходит в промежутках между обращениями (запросами) из БД. К примеру запрос происходит при старте монитора, потом через каждые 50 циклов (1цикл=200мс) т.е. около 10 с, так вот не при старте не спустя 10 с скачков не наблюдается, всё присходит ориентировочно в промежутках между обращениями. Когда открываем шаблон в среде разработки (на той же машине что и РТМ запускаем) проверяем запросы, связь с БД всё ОК, компилируем запускаем, что в профайлере что в РТМ, такая же картина! И такая картина не только в том проекте который есть у Вас но и в другом который разрабатывала сторонняя организация для нашей задачи и работает он сдругой БД и на другой машине. (там обмен с интервалом в 1 мин) Тогда вопросы: 1. Какие операции выполняет ТМ6.05.1 в промежутках между обращениями к БД? 2. Как можно диагностировать обмен с БД, но так чтоб выявить причину возникающей проблемы?// Вобщем господа, проверьте пожалуйста этот релиз на предмет работы с ODBC, почтой мы вам отправим скриншет с журналом просмотра событий ОС, там открыта как раз ошибка связанная с этим драйвером.
Posted by PMA (Участник № / Member № 1387) on :
Добрый день ! Действительно проблема появилась в релизе 6.05.1. При запуске канала выполняющего запись в таблицу MS SQL-2005,обязательно появляется сообщениие Calc Loop is Big и происходит потеря управления объектом на время от 5 до 10 сек, в это время система ни на что не реагирует, соответсвенно выходные сигналы не изменяются и происходит запаздывание, которое существенно влияет на состояние объекта. Запись в БД формируется 1 раз в 2 минуты. Когда я пишу, что система не реагирует, имеется в виду, что графика останавливается и через несколько секунд все значения изменяются скачком.
Posted by Grigorovskih (Участник № / Member № 1915) on :
Уважаемая техподдержка, вы проверяли обмен ч/з ODBC/SQL драйвер c SQL сервером? Сделайте простой тестоваый проект в котором будет запрос из БД и передача в каналы значений аргументов канала CALL вызова шаблона связи с этой БД и увидите что происходит! Если надо мы Вышлем разные варианты тестовых проектов где используются разные сервера (SQL базы) с log файлом трассировки, у всех у них те же проблемы которые мы описываем. У нас нет документации для анализа этого файла, попробуете разобраться что происходит при обмене. А главное, вы сами можете проверить всё и без нас, неужели у вас нет SQL сервера? Вы же писали на сайте, что проверяли работу релиза 6.05.1!
Posted by Grigorovskih (Участник № / Member № 1915) on :
Прямо сейчас накидали тестовый проект с разными шаблонами (но все они SELECT), запускали с разных машин и работали с разными базами, везде наблюдается большёй скачёк времени цикла при работе монитора, в файле трассировщика явных свидетельств об ошибках не наюлюдается, более того все запросы идут с ответами (видно из содержания этого же файла), но и там же наблюдается большая куча дополнительной информации. Уменьшали частоту запросов, уменьшали количество выбираемых данных (до одного значения!!!) превышений цикла меньше не становилось. Господа убедительно просим Вас проверьте пожалуйста у себя в тестовом режиме обмен с использованием драйвера SQL-ного, вы увиде то же самое, уверен на 99%.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Мы это обязательно проверим и незамедлительно сообщим о результатах.
Posted by Grigorovskih (Участник № / Member № 1915) on :
Здравствуйте уважаемые Господа разработчики!
Как у Вас идёт проверка? Есть какие нибудь мысли поэтому поводу?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
### Проблема в работе. Мы сообщим о результатах по завершении.
Posted by Grigorovskih (Участник № / Member № 1915) on :
Хорошо!
Posted by Grigorovskih (Участник № / Member № 1915) on :
Здравствуйте уважаемые Господа разработчики!
Мы конечно понимаем Вашу загруженность работой, но всё же и у нас тоже проблема эта висит не решённой. Как можно решить эту проблему в более короткий срок? Уже прошёл месяц, мы думаем что пора принять какое то решение в этом направлении! Надеемся на Ваше понимание!
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Настроил SQL Server 2005, подключение осуществлялось очень долго. Этот процесс мы будем изучать и, если сможем, оптимизировать.
Создание SQL запросов не заняло много времени.
Выполнение записи данных в БД не вызвало подвисаний системы. Осуществлялась запись 2 параметров по кнопке.
Чтение из базы также прошло без подвисаний. Считывались те же два параметра (без фильтров).
У нас SQL Server и проект запускались на одной машине. У Вас тоже или по сети? Можете прислать нам Ваши тестовые примерчики?
Posted by Grigorovskih (Участник № / Member № 1915) on :
Да по сети конечно, прислать сможем, хотя вроде уже присылали и отчёт (трассировщика ODBC) тоже...
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Отчет присылали, а вот тестовых проектов с БД не было. Пришлите, пожалуйста.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Проверили работу по сети. Зависаний также не было обнаружено. Ждем Ваших примеров.
Posted by Grigorovskih (Участник № / Member № 1915) on :
Здравствуйте уважаемая техподдержка!
Все необходимые материалы отправили на адрес техподдержки. Давайте будем разбираться с проблемой уважаемые Господа разработчики.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Проект получили. Будем разбираться. О результатах сообщим.
Posted by Grigorovskih (Участник № / Member № 1915) on :
Здравствуйте уважаемые господа разработчики!
Скажите пожалуйста в релизе 6.06 по этой тематике проблем не будет? Мы ждём результата теперь хотябы к новому релизу! Все исчерпывающие комментарии по проблеме (возникающей необратимой ситуации при определённых условиях, вплоть до повисания ОС) работы РТМ были отосланы на адрес техподдержки, так что повторяться не будем.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Для того, чтобы при потере соединения с базой данных этот канал не загружал всю систему его надо перевести в поток Idle. Переподключение в таком случае будет происходить без влияния на остальную систему.
Posted by Grigorovskih (Участник № / Member № 1915) on :
Да спасибо конечно, попробуем, только в поток idle переводить оба канала CALL, т.е тот что шаблон связи с БД вызывает и тот что посылает в его входное значение номер запроса? Но уважаемые Господа, ведь в версии 6.05 при процедурах восстановления связи с БД такого перегруза системы небыло. Поэтому мы очень обеспокоены как будут обстоять дела на эту тему в релизе 6.06!
Posted by Grigorovskih (Участник № / Member № 1915) on :
Господа можно чуть оперативнее отвечать!
Дайте пожалуйста ответ на вопрос: в поток idle переводить оба канала CALL, т.е тот что шаблон связи с БД вызывает и тот что посылает в его входное значение номер запроса?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Достаточно перевести в поток idle только канал вызывающий шаблон связи с БД.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Данная проблема возникла из-за того, что начиная с релиза 6.05.1 все SQL операции были переведены в основной поток для ускорения их реализации. До этого SQL операции производились в потоке IDLE.
Posted by Grigorovskih (Участник № / Member № 1915) on :
... Да, действительно после перевода в поток idle канала, вызывающего шаблон связи с БД, мониторы стали работать более устойчиво, т.е. при любых нарушениях касающихся связи с удалённой БД, и в том числе перезагрузки удалённого сервера под которым она работает, РТМ что называется "колом" не встаёт, но если он не засыпет сообщениями операционку, в ОС число открытых окон зависит от ресурсов железа и является ограниченным. Но не смотря на это Вам всё таки ещё надо поработать с процедурами которые определяют обмен с драйвером ODBC, ввести некое подобие таймаута для отключеня канала (выставлять недостоверность) отвечающего за обмен с БД в проекте в случаях любых нарушений работы даже самого драйвера. Можете провести следующий эксперимент: У Вас есть проект ранее нами отправленный, который очень интенсивно ведёт обмен с удалённой БД. Но можете и свой сделать на скорую руку. 1. Запускаем трассировщик ODBC. 2. Запускаем РТМ, работаем. 3. Во время работы РТМа останавливаем трассировщик. После 3-го шага РТМ "вылетает" сообщив об ошибке и предлагая запустить отладчик.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Попробовали Ваш вариант. Не получилось. "Вылета" МРВ не удалось добиться, даже удалив соответствующий драйвер.
