Не удается обойти или преодолеть утечку памяти при работе c БД Paradox.
Пробовал использовать стандартный класс CDatabase при многократном вызове функций OpenEx и Close — происходит утечка.
Переписал с использованием ADO — эффекта ноль.
если фрагмент закомментирован пиковая загрузка памяти стабильна,
если раскомментировать стабильно течет на каждой итерации ~18кБ/за итерацию
коннект к БД всегда проходит успешно (во всех моих тестах было так)
rorex_ wrote:
> _conn->Open(_bstr_t(db_arc_conn.c_str()), _bstr_t(""), _bstr_t(""), ADODB::adConnectUnspecified); > _m_pConn->Close();
А это правда разные переменные используются или опечатка при переписывании в форум?
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>rorex_ wrote:
>> _conn->Open(_bstr_t(db_arc_conn.c_str()), _bstr_t(""), _bstr_t(""), ADODB::adConnectUnspecified); >> _m_pConn->Close(); .>А это правда разные переменные используются или опечатка при переписывании в форум?
спасибо за отклик!
да действительно опечатка — копировал только часть кода, пришлось подправлять на ходу
rorex_ wrote:
> минимизировал код до нескольких проблемных строк, но найти источник бед > так и не удается > найти альтернативу тоже пока не удается, просто засада ...
Трудно сказать... В приведённых строках я ничего криминального не вижу. Вполне возможно, что бага в самом драйвере.
В этом случае либо поискать альтернативу, либо сделать пул соединений — чтобы в процессе работы программы они не открывались/закрывались постоянно, а переиспользовались.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>rorex_ wrote:
>> минимизировал код до нескольких проблемных строк, но найти источник бед >> так и не удается >> найти альтернативу тоже пока не удается, просто засада ... .>Трудно сказать... В приведённых строках я ничего криминального не вижу. Вполне возможно, что бага в самом драйвере. .>В этом случае либо поискать альтернативу, либо сделать пул соединений — чтобы в процессе работы программы они не открывались/закрывались постоянно, а переиспользовались.
Спасибо за ответ, альтернативу уже пробовал искать — безрезультатно, во втором случае возникают трудности с (моно/много)пользовательским режимом работы Paradox. Сейчас я работаю с копией таблиц (сторонние разработчики используют блокировку доступа к данным (монорежим)). Собственно сам алгоритм моей программы: получаю копию таблиц, открываю локальное соединиение, считываю данные, закрываю соединение, удаляю временные файлы. Если соединение не закрыть, удалить файлы не получается. Если открывать/закрывать — течет память.
Есть еще вариант найти какой нибудь конвертер или переписать библиотечку на дельфи. Не знаю только как в этом случае с ней будет работать OPC DA сервер в который я собственно и загружаю данные.
В конечном утечка прекратилась после перестройки DSN с драйвера Microsoft Paradox Driver на Microsoft Access Paradox Driver.
Соответственно вместо библиотеки "c:/windows/system32/odbcjt32.dll" выполнение запросов пошло через "C:/Program Files/Common Files/Microsoft Shared/OFFICE12/aceodbc.dll"