Вопрос знатокам:

Не удается обойти или преодолеть утечку памяти при работе c БД Paradox.

Пробовал использовать стандартный класс CDatabase при многократном вызове функций OpenEx и Close — происходит утечка.
Переписал с использованием ADO — эффекта ноль.

блок программы

...............
while(true)
{
    .............
/*
    _conn->Open(_bstr_t(db_arc_conn.c_str()), _bstr_t(""), _bstr_t(""), ADODB::adConnectUnspecified);
    if (_m_pConn->GetState() == ADODB::adStateOpen)
    {
    _m_pConn->Close();
    }
*/
    .............
}
...............

если фрагмент закомментирован пиковая загрузка памяти стабильна,
если раскомментировать стабильно течет на каждой итерации ~18кБ/за итерацию
коннект к БД всегда проходит успешно (во всех моих тестах было так)

Строка подключения:

db_src_conn = "DSN=unitokdb;AUT=1;CT=7;DQ=0;FOC=0;IS=1;PW=myPassword;USF=1;ULQ=1;"

Использую Microsoft Paradox Driver v.5. Пробовал 3,4 — эффект тот же.

Если использовать другую строку подключения (например для подключений к БД MySQL) утечка прекращается.

Версия ОС — WinXP SP2, MDAC 2.81

rorex_ wrote:

> _conn->Open(_bstr_t(db_arc_conn.c_str()), _bstr_t(""), _bstr_t(""), ADODB::adConnectUnspecified);
> _m_pConn->Close();
А это правда разные переменные используются или опечатка при переписывании в форум?

Здравствуйте, ., Вы писали:

.>rorex_ wrote:

>> _conn->Open(_bstr_t(db_arc_conn.c_str()), _bstr_t(""), _bstr_t(""), ADODB::adConnectUnspecified);
>> _m_pConn->Close();
.>А это правда разные переменные используются или опечатка при переписывании в форум?

спасибо за отклик!
да действительно опечатка — копировал только часть кода, пришлось подправлять на ходу

    _m_pConn->Open(_bstr_t(db_arc_conn.c_str()), _bstr_t(""), _bstr_t(""), ADODB::adConnectUnspecified);
    if (_m_pConn->GetState() == ADODB::adStateOpen)
    {
    _m_pConn->Close();
    }

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

rorex_ wrote:

> минимизировал код до нескольких проблемных строк, но найти источник бед
> так и не удается
> найти альтернативу тоже пока не удается, просто засада ...
Трудно сказать... В приведённых строках я ничего криминального не вижу. Вполне возможно, что бага в самом драйвере.
В этом случае либо поискать альтернативу, либо сделать пул соединений — чтобы в процессе работы программы они не открывались/закрывались постоянно, а переиспользовались.

Здравствуйте, ., Вы писали:

.>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"