Тема / Topic: Проблема с ODBC при переходе на Windows 7
Сергей Морозов
Active Forum Member / Активный участник форума
Участник № / Member № 2076
отправлено / posted
Здравствуйте. Помогите разобраться с проблемой при переносе проекта. Проект версии 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 и семерке (проверил на нескольких машинах) выглядит примерно одинаково за исключением одного фрагмента. На семерке, при нормально работающих запросах, при каждом запросе появляется:
Такая же проблема появилась при переносе еще одного проекта. И, я думаю, появится при последующих переносов. Переход на более позднюю версию ТМ невозможен из-за несовместимости каналов call.otherproj.
Сообщения / Posts 98 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Проект версии 6.08 перенесен без каких либо изменений с Windows XP на Windows 7. Релиз 6.08 был выпущен порядка 10 лет назад. Указанные ОС давно сняты с поддержки Microsoft'ом. Рекомендуем использовать актуальные версии Продуктов.
За время между выпуском 6.08 и 6.10.2 были устранены все известные (на момент выпуска 6.10.2) ошибки.
После актуализации ТМ и ОС сообщите воспроизводится проблема или нет.
Переход на более позднюю версию ТМ невозможен из-за несовместимости каналов call.otherproj. Указанная проблема нам не известна. Опишите ее подробнее.
Сейчас есть только два запроса с периодом 30 секунд каждый. Вы контролируете факт завершения выполнения SQL-запроса или бесконтрольно с заданной периодичностью подаете команду на запись в БД?
Опишите решаемую задачу. Зачем так часто записывать в БД? Какой объем записываемых данных?
Сергей Морозов
Active Forum Member / Активный участник форума
Участник № / Member № 2076
отправлено / posted
Переход на более позднюю версию ТМ невозможен из-за несовместимости каналов call.otherproj. Указанная проблема нам не известна. Опишите ее подробнее.
Сейчас есть только два запроса с периодом 30 секунд каждый. Вы контролируете факт завершения выполнения SQL-запроса или бесконтрольно с заданной периодичностью подаете команду на запись в БД?
Не контролирую. При нормальной работе нет необходимости. В обоих таблицах есть поле времени. В первой таблице оно всегда заканчивается на :00 и :30 секунд. Во второй, в худшем случае, на :02 и :32 секунды. Т.е. запросы выполняются примерно 4 секунды, что много меньше 30.
Опишите решаемую задачу. Зачем так часто записывать в БД? Какой объем записываемых данных?
Требование ПТО, архивы для хранения и анализа. В первом запросе 60 полей типа REAL, во втором 90. Плюс поле дата-время в обеих таблицах. На некоторых машинах под Win XP порядка 10 запросов примерно с таким же количеством полей, проблем нет.
Сообщения / Posts 98 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Известна. Понятно. В указанном топике все объяснено. Релизы должны быть синхронными. Рекомендуем использовать актуальный релиз 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 17114 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Сергей Морозов
Active Forum Member / Активный участник форума
Участник № / Member № 2076
отправлено / posted
Вы так же можете использовать рекомендацию из сообщения номер 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 |
Сергей Морозов
Active Forum Member / Активный участник форума
Участник № / Member № 2076
отправлено / posted
И возвращаюсь к трассировке. Почему в Win XP нет, а в Win 7 есть сообщение:
Проверено на четырех XP, с разными проектами. И на тре[ Win 7, так же с разными проектами.
Сообщения / Posts 98 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
По факту рекомендация сводится к покупке примерно 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 17114 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
И возвращаюсь к трассировке. Почему в Win XP нет, а в Win 7 есть сообщение:
rtcx a34-f08 EXIT SQLDriverConnectW with return code 0 (SQL_SUCCESS) Если проект не изменялся, а менялась ОС, то необходимо искать отличия в настройке или работе непосредственно ОС.
И, как Вы видите, (SQL_SUCCESS). Запрос выполнен успешно. А сообщение <Invalid buffer length!> может быть вызвано несоответствием в настройках обмена разных ОС. С этим вопросом стоит обратиться на специализированные форумы.
Сообщения / Posts 17114 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Printer-friendly view of this topic
