Доброго времени суток, ALL!!!
давненько использую OLEDB для доступа к базам (ATL). В основном к MSSQL. поэтому поддержку восстановления при сбое отлаживал на нем.
работает след образом
при первом обращении к базе вызывается:
HRESULT ColeDB_base::OpenDataSource(void)
{
if (m_session) return S_OK;
HRESULT hr=S_FALSE;
while(!m_session)
{
CDataSource db;
CDBPropSet dbinit(DBPROPSET_DBINIT);
dbinit.AddProperty(DBPROP_AUTH_PASSWORD, db_passw.c_str());
dbinit.AddProperty(DBPROP_AUTH_USERID, db_user.c_str());
if (m_bs==MSSQL) dbinit.AddProperty(DBPROP_INIT_CATALOG, db_base.c_str());
dbinit.AddProperty(DBPROP_INIT_DATASOURCE, db_server.c_str());
dbinit.AddProperty(DBPROP_INIT_LCID, (long)1049);
dbinit.AddProperty(DBPROP_INIT_PROMPT, (short)4);
switch(m_bs)
{
case MSSQL:
hr = db.Open(_T("SQLOLEDB.1"), &dbinit);
break;
case ORA:
hr = db.Open(_T("MSDAORA"), &dbinit);
break;
}
if (FAILED(hr))
{
continue;
}
m_session = new CSession;
if (!m_session) continue;
hr = m_session->Open(db);
if (SUCCEEDED(hr))
{
m_connect = true;
return hr;
}
if (m_session)
{
delete m_session;
m_session=NULL;
}
}
return hr;
}
если что-то случилось то уничтожается объект CSession (m_session), а при след обращении к базе создается новый объект CSession этим же кодом...
это работает уже не первый год... но с MSSQL. как я наивно считал что и с MSDAORA тоже работает и даже не проверял
но рак на горе свистнул — пропало соединение с сервером oracle и оказалось что это не работает
строка hr = db.Open(_T("MSDAORA"), &dbinit); вываливает в int 3... причем где то в недрах NTDLL...
где смотреть? как обеспечить постоянное и надежное соединение (если где то что-то упало чтоб оно само могло восстановиться) на OLEDB ? причем независимо от провайдера...
пишу код одинковый — только меняю сервера — то MSSQL, то ORACLE, с MSSQL все замечательно (искуственно вставляю дисконнект с базой (уничтожающий m_session)). Стоит пересобрать тестовый проект для работы с ORACLE — первый вызов хранимой процедуры успешен, дисконнект успешен, а повторный вызов db.Open(_T("MSDAORA"), &dbinit); ломается — HEAP: Free Heap block 1b9fd40 modified at 1b9ff08 after it was freed.
извиняюсь что утомил... неделю бьюсь — ни в какую...
скачал новую библиотеку msdaora.dll — то же самое...
очень надеюсь на Ваш совет!!!
заранее огромное спасибо за внимание!!!
03.10.05 16:02: Перенесено из 'C/C++. Прикладные вопросы'
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, podaa, Вы писали:
P>причем как пишут в достоинствах — мол единообразный доступ к различным данным...
Формально это так. На практике... ну я, например, знаю ловушки для неискушенного пользователя, в которые он сам рад попадаться. Думать-то никто не хочет
P>может ларчик проще открывается — в CDBPropSet нужно какое-нибудь специфическое свойсво выставить...
Посмотри свойства через "Rowset Viewer" — это очень полезная хреновина из MDAC SDK
P>еще вопрос — родной провайдер с клиентом оракловским ставится?
Да. Может есть способ попроще, но я его не знаю.
P>какой у него ProgID ?
Насчет ProgID — что-то типа "ORAOLEDB". Через "Rowset Viewer" увидешь
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Доброго времени суток!
долго и упорно искал провайдера от производителя БД
наконец нашел — поставился он _только_ если ставить базу данных (в клиенте нет ни в одной кофигурации) причем Oracle9i , в дистрибутиве 8-го такого зверя не оказалось совсем. Там всего то 8 dll и один tlb файлик (все вместе около 800 кб) (интересно почему на сайте оракла дистрибутив этого дела весит 120 мб?)
и самое интересное — все работает!!! в программе не поменял ни строчки кроме ProgID конечно... и все стало на свои места...
огромное спасибо за совет
(с MSDAORA надобы конечно повоевать до победного... но опосля...)
Здравствуйте, podaa, Вы писали:
P>Доброго времени суток!
P>долго и упорно искал провайдера от производителя БД
P>и самое интересное — все работает!!! в программе не поменял ни строчки кроме ProgID конечно... и все стало на свои места...
Ну, это, типа ты главное помни, что приличные OLEDB провайдеры могут писать не только производители DBMS
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Здравствуйте, podaa, Вы писали:
P>>Доброго времени суток!
P>>долго и упорно искал провайдера от производителя БД
P>>и самое интересное — все работает!!! в программе не поменял ни строчки кроме ProgID конечно... и все стало на свои места...
КД>Ну, это, типа ты главное помни, что приличные OLEDB провайдеры могут писать не только производители DBMS
поспешил я тады со "своими местами" малехо... да закрутился и сразу не написал про это
у родного провайдера оказалось интересное свойство — он нуль в конец строк в возвращаемых параметрах не ставит... ну думаю — удивил, взял всю строку нулями заполнил (это OUTPUT параметр) перед вызовом... и тут удивлению не было предела — ERRORSINCOMMAND стало возвращать при выполнении... команда осталась старая — я просто память под параметр (возвращаемый!!!) нулями забил (забивал полностью, ставил только первый байт нулевой, ради прикола записывал туда какую-нить строчку — эффект один — ERRORSINCOMMAND) пока не победил, переменные где в сгенеренном для хранимой процедуры классе хранится длина возвращаемой строки не нашел...
ну обернул я старый вызов (с родным провайдером) в __try {} __except(EXCEPTION_EXECUTE_HANDLER){/*тут нечто сохраняющее лог*/}
под отладчиком работать плохо — останавливает конечно, но что самое интересно — когда запускаю не под отладчиком, и debug и release версию — в блок __except не попало еще ни разу (работает все время ровно неделю, связь конечно не пропадает все время, но по специфике работы иногда делается дисконнект от базы (там xml чего то где то криво накапливает — сессия потихоньку но неумолимо замедляется, пока админы ищут приччину — работать то надо...))
одно настораживает — что не попало _пока_... обнадежишься по этому поводу а оно рухнет совсем в самый неподходящий момент...
