Форум TRACE MODE: техническая поддержка Послать новую тему / Post New Topic  Послать ответ / Post A Reply
мой профиль / my profile авторизация / login | регистрация / register | поиск / search | часто задаваемые вопросы / faq | начало / forum home

  Следующая старая тема / next oldest topic   Следующая новая тема / next newest topic
» Форум TRACE MODE: техническая поддержка » ТЕХНИЧЕСКАЯ ПОДДЕРЖКА / TECHNICAL SUPPORT TRACE MODE 6 » Работа с приложениями (ODBC-SQL/OPC/DDE) » Проблема с ODBC при переходе на Windows 7

   
Автор / Author Тема / Topic: Проблема с ODBC при переходе на Windows 7
Сергей Морозов
Active Forum Member / Активный участник форума
Участник № / Member № 2076


Icon 1 отправлено / posted      Профиль для / Profile for Сергей Морозов           Редактировать/удалить сообщение / Edit/Delete Post   Вставить в ответ текст исходного сообщения  / Reply With Quote 
Здравствуйте. Помогите разобраться с проблемой при переносе проекта.
Проект версии 6.08 перенесен без каких либо изменений с Windows XP на Windows 7. Проект проработал примерно две недели. Затем прекратилась запись в базы данных Access (запросы Insert). После перезапуска ПК история повторились.
Попытки изменить свойства каналов SQLQuery (input/output, перенос в цикл IDLE) а так же разнести запросы по времени ничего не дали. Сейчас есть только два запроса с периодом 30 секунд каждый.
Обратил внимание процесс rtcx.exe постепенно пожирает всю память. Сделал кнопку разрешения/запрета запросов к БД. В результате при отсутствии запросов две недели rtcx потребляет 144 Мб. После разрешения запросов загрузка память начинает расти примерно на 60 Мб в сутки.

В момент аварийного прекращения записи в БД лог выглядит так:
(19:47:0) INF_RTM:SQL: connect psv4asu1_1
(19:47:0) INF_RTM:SQL: exec all psv4asu1_1
(19:47:0) INF_RTM:SQL: waite other request execute psv4asu1_2
(19:47:1) INF_RTM:SQL: waite other request execute psv4asu1_2
(19:47:2) INF_RTM:SQL: disconnect after execute psv4asu1_1
(19:47:3) INF_RTM:SQL: connect psv4asu1_2
(19:47:3) INF_RTM:SQL: exec all psv4asu1_2
(19:47:30) INF_RTM:SQL: waite other request execute psv4asu1_1
(19:47:31) INF_RTM:SQL: waite other request execute psv4asu1_1
(19:47:32) INF_RTM:SQL: waite other request execute psv4asu1_1
(19:47:33) INF_RTM:SQL: waite other request execute psv4asu1_1
(19:47:34) INF_RTM:SQL: waite other request execute psv4asu1_1
(19:47:35) INF_RTM:SQL: waite other request execute psv4asu1_1

а трассировщик сообщает:
DIAG [S1001] [Microsoft][Драйвер ODBC Microsoft Access] Недостаточно системных ресурсов. (-1011)

Попытки обновить ODBC драйвер или перейти с драйвера mdb на драйвер mdb, assdb результата то же не дали.
Еще заметил трассировка на XP и семерке (проверил на нескольких машинах) выглядит примерно одинаково за исключением одного фрагмента. На семерке, при нормально работающих запросах, при каждом запросе появляется:

rtcx a34-f08 EXIT SQLDriverConnectW with return code 0 (SQL_SUCCESS)
HDBC 0x0156EEB0
HWND 0x00000000
WCHAR * 0x6DD28B34 [ -3] "******\ 0"
SWORD -3
WCHAR * 0x6DD28B34 <Invalid buffer length!> [-3]
SWORD -3
SWORD * 0x00000000
UWORD 0 <SQL_DRIVER_NOPROMPT>

Такая же проблема появилась при переносе еще одного проекта. И, я думаю, появится при последующих переносов.
Переход на более позднюю версию ТМ невозможен из-за несовместимости каналов call.otherproj.

Сообщения / Posts 98 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
АдАстра. Техподдержка
Administrator
Участник № / Member № 4


Icon 1 отправлено / posted      Профиль для / Profile for АдАстра. Техподдержка           Редактировать/удалить сообщение / Edit/Delete Post   Вставить в ответ текст исходного сообщения  / Reply With Quote 
Проект версии 6.08 перенесен без каких либо изменений с Windows XP на Windows 7.
Релиз 6.08 был выпущен порядка 10 лет назад.
Указанные ОС давно сняты с поддержки Microsoft'ом.
Рекомендуем использовать актуальные версии Продуктов.

За время между выпуском 6.08 и 6.10.2 были устранены все известные (на момент выпуска 6.10.2) ошибки.

После актуализации ТМ и ОС сообщите воспроизводится проблема или нет.

Переход на более позднюю версию ТМ невозможен из-за несовместимости каналов call.otherproj.
Указанная проблема нам не известна. Опишите ее подробнее.

Сейчас есть только два запроса с периодом 30 секунд каждый.
Вы контролируете факт завершения выполнения SQL-запроса или бесконтрольно с заданной периодичностью подаете команду на запись в БД?

Опишите решаемую задачу. Зачем так часто записывать в БД? Какой объем записываемых данных?

[ 27.07.2023, 13:57: Сообщение отредактировал / Message edited by АдАстра. Техподдержка ]

Сообщения / Posts 17232 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
Сергей Морозов
Active Forum Member / Активный участник форума
Участник № / Member № 2076


Icon 1 отправлено / posted      Профиль для / Profile for Сергей Морозов           Редактировать/удалить сообщение / Edit/Delete Post   Вставить в ответ текст исходного сообщения  / Reply With Quote 
Переход на более позднюю версию ТМ невозможен из-за несовместимости каналов call.otherproj.
Указанная проблема нам не известна. Опишите ее подробнее.

Известна.

Сейчас есть только два запроса с периодом 30 секунд каждый.
Вы контролируете факт завершения выполнения SQL-запроса или бесконтрольно с заданной периодичностью подаете команду на запись в БД?

Не контролирую. При нормальной работе нет необходимости. В обоих таблицах есть поле времени. В первой таблице оно всегда заканчивается на :00 и :30 секунд. Во второй, в худшем случае, на :02 и :32 секунды. Т.е. запросы выполняются примерно 4 секунды, что много меньше 30.

Опишите решаемую задачу. Зачем так часто записывать в БД? Какой объем записываемых данных?

Требование ПТО, архивы для хранения и анализа. В первом запросе 60 полей типа REAL, во втором 90. Плюс поле дата-время в обеих таблицах.
На некоторых машинах под Win XP порядка 10 запросов примерно с таким же количеством полей, проблем нет.

Сообщения / Posts 98 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
АдАстра. Техподдержка
Administrator
Участник № / Member № 4


Icon 1 отправлено / posted      Профиль для / Profile for АдАстра. Техподдержка           Редактировать/удалить сообщение / Edit/Delete Post   Вставить в ответ текст исходного сообщения  / Reply With Quote 
Известна.
Понятно. В указанном топике все объяснено. Релизы должны быть синхронными.
Рекомендуем использовать актуальный релиз 6.10.2.
Вы так же можете использовать рекомендацию из сообщения номер 2 (ссылка)

Не контролирую. При нормальной работе нет необходимости. В обоих таблицах есть поле времени. В первой таблице оно всегда заканчивается на :00 и :30 секунд. Во второй, в худшем случае, на :02 и :32 секунды. Т.е. запросы выполняются примерно 4 секунды, что много меньше 30.
Рекомендую, как минимум, визуально проконтролировать значение атрибута 0,R канала Call.SQLQuery (после получения подтверждения выполнения sql-запроса ODBC-драйвером в канале Call.SQLQuery значение атрибута должно сбросится в 0).
Драйвер ODBC работает последовательно. И если один запрос не успел отработать, и был подан новый, то происходит буферизация запросов. В обычном случае, буфер по мере реализации запросов, будет очищаться. Но если запросы будут приходить быстрее, чем их исполняют, то это может привести к истощению свободных ресурсов ПК.

В релизе 6.10.2 есть канал Call.AsyncCollection, который позволяет реализовать последовательное выполнение привязанных каналов Call (в том числе Call.Query). Это позволит избежать переполнения буфера sql-запросов.

Отдельно стоит проверить воспроизводится описанная Вами проблема при наличии в проекте одного канала Call.SQLQuery.

Сообщения / Posts 17232 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
Сергей Морозов
Active Forum Member / Активный участник форума
Участник № / Member № 2076


Icon 1 отправлено / posted      Профиль для / Profile for Сергей Морозов           Редактировать/удалить сообщение / Edit/Delete Post   Вставить в ответ текст исходного сообщения  / Reply With Quote 
Вы так же можете использовать рекомендацию из сообщения номер 2
По факту рекомендация сводится к покупке примерно 15 МРВ с поддержкой ОРС, неприемлемо.

Рекомендую, как минимум, визуально проконтролировать значение атрибута 0,R канала Call.SQLQuery (после получения подтверждения выполнения sql-запроса ODBC-драйвером в канале Call.SQLQuery значение атрибута должно сбросится в 0).
Да, это я проделывал, все происходит как и должнО, появляется 1, затем сбрасывается в 0. Так происходит пока все работает, потом повисает единица.

Драйвер ODBC работает последовательно. И если один запрос не успел отработать, и был подан новый, то происходит буферизация запросов.
Пробовал разнести запросы по времени, со сдвигом 5 секунд, результат тот же.

В релизе 6.10.2 ... Опять же возвращиемся к каналу Otherproj.

Отдельно стоит проверить воспроизводится описанная Вами проблема при наличии в проекте одного канала Call.SQLQuery.
Ну, предположим, исчезнет проблема. Что дальше? Плюс я ограничен в проведении экспериментов, это не учебный стенд, это реальный объект.

Сообщения / Posts 98 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
Сергей Морозов
Active Forum Member / Активный участник форума
Участник № / Member № 2076


Icon 1 отправлено / posted      Профиль для / Profile for Сергей Морозов           Редактировать/удалить сообщение / Edit/Delete Post   Вставить в ответ текст исходного сообщения  / Reply With Quote 
И возвращаюсь к трассировке. Почему в Win XP нет, а в Win 7 есть сообщение:

rtcx a34-f08 EXIT SQLDriverConnectW with return code 0 (SQL_SUCCESS)
HDBC 0x0156EEB0
HWND 0x00000000
WCHAR * 0x6DD28B34 [ -3] "******\ 0"
SWORD -3
WCHAR * 0x6DD28B34 <Invalid buffer length!> [-3]
SWORD -3
SWORD * 0x00000000
UWORD 0 <SQL_DRIVER_NOPROMPT>

Проверено на четырех XP, с разными проектами. И на тре[ Win 7, так же с разными проектами.

Сообщения / Posts 98 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
АдАстра. Техподдержка
Administrator
Участник № / Member № 4


Icon 1 отправлено / posted      Профиль для / Profile for АдАстра. Техподдержка           Редактировать/удалить сообщение / Edit/Delete Post   Вставить в ответ текст исходного сообщения  / Reply With Quote 
По факту рекомендация сводится к покупке примерно 15 МРВ с поддержкой ОРС, неприемлемо.
Вы не правы.
Рекомендаций несколько и использование OPC последнее из них.
Я дал ссылку на пост, в котором дана рекомендация Начиная с релиза 6.09 вплоть до релиза 6.10.2 межрелизовый обмен с помощью каналов CALL.OtherProj осуществляется.
Т.е. переведите все проекты на 6.09 и выше. Рекомендуем 6.10.2

Вы так же можете перевести все проекты на 6.08.
Стоит учесть, что оставаясь на 6.08, у Вас останутся ошибки, который устранены в последующих релизах.
За время между выпуском 6.08 и 6.10.2 были устранены все известные (на момент выпуска 6.10.2) ошибки.

И только в случае невозможности реализовать один из двух вариантов, используйте вариант с OPC.

появляется 1, затем сбрасывается в 0
Если 1 одномоментно появляется у одного из двух каналов Call.SQLQuery, то это хорошо.

Пробовал разнести запросы по времени, со сдвигом 5 секунд, результат тот же.
Не важно, на сколько Вы сдвинули запрос. Запрос имеет длительность (от момента подачи команды, то получения подтверждения о завершении (сброс значения канала в 0)). Необходимо убедится в том, что одномоментно отрабатывается один запрос (у одного канала Реального значение равно 1).

В релизе 6.10.2 ... Опять же возвращиемся к каналу Otherproj.
За время между выпуском 6.08 и 6.10.2 были устранены все известные (на момент выпуска 6.10.2) ошибки.
По вопросу Call.OtherProj ответ дан выше.

Ну, предположим, исчезнет проблема. Что дальше?
Если при наличии одного sql-запроса проблемы нет, а при наличии двух есть, то это подтвердит необходимость правильно разнести запросы по времени. И следовательно решение будет очевидным - AsyncCollection или реализация своего шаблона программы, который будет подавать команду на реализацию sql-запроса с учетом выполнения предыдущего запроса.

Плюс я ограничен в проведении экспериментов, это не учебный стенд, это реальный объект.
Если Вы знаете структуру используемой БД и имеете копию проекта, то у Вас есть все необходимое для реализации независимого стенда.

Проект версии 6.08 перенесен без каких либо изменений с Windows XP на Windows 7
Если проект переносился без внесения изменений, то стоит рассмотреть различия в настройках указанных двух ОС.

Сообщения / Posts 17232 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
АдАстра. Техподдержка
Administrator
Участник № / Member № 4


Icon 1 отправлено / posted      Профиль для / Profile for АдАстра. Техподдержка           Редактировать/удалить сообщение / Edit/Delete Post   Вставить в ответ текст исходного сообщения  / Reply With Quote 
И возвращаюсь к трассировке. Почему в Win XP нет, а в Win 7 есть сообщение:

rtcx a34-f08 EXIT SQLDriverConnectW with return code 0 (SQL_SUCCESS)

Если проект не изменялся, а менялась ОС, то необходимо искать отличия в настройке или работе непосредственно ОС.

И, как Вы видите, (SQL_SUCCESS). Запрос выполнен успешно.
А сообщение <Invalid buffer length!> может быть вызвано несоответствием в настройках обмена разных ОС. С этим вопросом стоит обратиться на специализированные форумы.

Сообщения / Posts 17232 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
   

Quick Reply
Сообщение / Message:

HTML код не разрешен. / HTML is not enabled.
UBB код разрешен. / UBB Code is enabled.

Значки Graemlins / Instant Graemlins
   


Послать новую тему / Post New Topic  Послать ответ / Post A Reply Закрыть тему / Close Topic   Feature Topic   Переместить топик / Move Topic   Удалить топик / Delete Topic Следующая старая тема / next oldest topic   Следующая новая тема / next newest topic
 - Printer-friendly view of this topic
Перейти к / Hop To


Новости АСУ ТП / News | SCADA / HMI | Обучение / Trainings | Свяжитесь с нами / Contact Us



Powered by Infopop Corporation
UBB.classic™ 6.7.2