Форум: "Базы";
Текущий архив: 2003.05.08;
Скачать: [xml.tar.bz2];
ВнизDirect Oracle Access возобновление подключения к базе !? Найти похожие ветки
← →
YDV (2003-04-15 09:38) [0]Доброго Вам времени суток !
Кто-нибудь сталкивался с проблемой возобновления соединения с сервером СУБД ORACLE при случайном разрыве соединения с БД, перегрузки сервера или другого обстоятельства, повлекшего за собой разрыв соединения с клиентским приложением ?
При попытке возобновить подключение возникает системная ошибка, которая полностью выгружает прогу, либо вешает ее ...
Заранее спасибо за ответ !
← →
Sergey13 (2003-04-15 10:14) [1]2YDV (15.04.03 09:38)
>При попытке возобновить подключение возникает системная ошибка
Как возобновляешь и что за ошибка?
ИМХО лучше перезапустить приложение.
← →
EthernalWonderer (2003-04-15 12:41) [2]Присоединяюсь к вопросу. Мой ODAC после обрыва соединения (вытаскиваем шнур) при первом же обращении к серверу пишет: Windows socket error (10054), а затем после востановления (воткнули обратно) подключения при попытке connected := True пишет: "IO error". Перезапуск программы, как всегда, помогает, но хочется как лучше ...
Кто - нибудь боролся с этим? Какие соображения?
← →
blackman (2003-04-15 13:41) [3]connected := False
а потом
connected := True
← →
YDV (2003-04-15 18:55) [4]>Sergey13:
возобновляю как раз как написал blackman:
> blackman © (15.04.03 13:41)
> connected := False
> а потом
> connected := True
в ошибке что-то связано с иструкцией по адресу ...
← →
Sergey13 (2003-04-16 08:41) [5]2YDV (15.04.03 18:55)
2blackman © (15.04.03 13:41)
> connected := False
> а потом
> connected := True
А идентификатор сессии при этом не меняется? Ведь коннект пропал не только для клиента, но и для сервера.
← →
EthernalWonderer (2003-04-16 14:22) [6]>blackman © (15.04.03 13:41)
>connected := False
Любое обращение после обрыва соединения к OraSession (например, OraSession1.Free) вызывает ошибку IO Error.
>Sergey13 © (16.04.03 08:41)
Идентификатор сессии меняется при disconnect/connect.
В случае обрыва сервер узнает об этом через некоторое время и обрубит сессию. При этом откатятся все незафиксированные изменения. Конечно, нелохо было бы попытаться подключиться к оборванной сессии, но, скорее всего, с этим уже ничего не поделать, и это, в общем - то, терпимо: говорим юзеру, дескать, аварийная ситуация, все Ваши изменения похоронены. Но дальше желательно предложить ему подождать восстановления соединения, периодически делать ping и при появлении ответа сервера попытаться соединиться (Connect:=True) - а вот последнее и не получается, поскольку любое обращение к OraSession вызывает IO Error.
>Sergey13 © (15.04.03 10:14)
>ИМХО лучше перезапустить приложение
Не лучше, потому что форменное безобразие происходит при закрытии программы после обрыва - куча сообщений об ошибках, источник которых неизвестен вследствие отсутствия Sources ODAC ...
← →
EthernalWonderer (2003-04-16 14:26) [7]Может, в следующих версиях ODAC что-либо предпринято в этом направлении?
← →
EthernalWonderer (2003-04-17 09:40) [8]Тупик?
← →
Sergey13 (2003-04-17 10:41) [9]2EthernalWonderer (16.04.03 14:22)
>В случае обрыва сервер узнает об этом через некоторое время и обрубит сессию
Точно, но это время НЕОПРЕДЕЛЕННО - может через 5 минут, а может через 0.5 секунды - как повезет.
>Но дальше желательно предложить ему подождать восстановления соединения
Предложить можно. Но реально делать это не стоит, ИМХО. Так как проблема, привежшая к обрыву связи, чаще всего не решается сама по себе за 1 минуту.
>Не лучше, потому что форменное безобразие происходит при закрытии программы после обрыва
Надо показать пользователю трехпальцевую комбинацию. 8-) Все равно эфект от ожидания/пингования/корректного переконекта будет примерно таким же. 8-)
>вследствие отсутствия Sources ODAC
Вообще то в вопросе был DOA.
Это хреново, когда рвется связь. Если это происходит так часто, что на это надо реагировать программно, то это хреново в квадрате. ИМХО, если это происходит, надо зрить в корень, и думать над сменой аппартной части системы.
← →
blackman (2003-04-17 10:49) [10]>Sergey13
Это уже проблемы настройки сервера, а не клиента.
DELPHI здесь ни при чем.
← →
Sergey13 (2003-04-17 11:56) [11]2blackman © (17.04.03 10:49)
>>Sergey13
>Это уже проблемы настройки сервера, а не клиента.
Не понял. Ты про что? Настроить сервер чтоб не отывался? 8-)
>DELPHI здесь ни при чем.
Дык и я за то. Три пальца спасут кого угодно, даже отца русской демократии. 8-)
← →
YDV (2003-04-17 13:01) [12]>Sergey13:
SessionID меняется !, но для меня это не проблема - главное коннект восстановить, ну а потом данные еще разок перечитаем, сделаем что нужно и попробуем их скинуть на сервер и коммитнуть(если связь не оборвется :( .)...
проблема в том, что когда связь обывается, ето выцепляю, пытаюсь сделать реконнет и тут:
Access violation at address 6139DBED in module "ORA805.dll".Read adress FFFFFFFF.
а вот вчера я обнаружил что повторный реконнект вроди как работает, SessionID не проверял(скорее всего он меняется), но для меня скорей всего придется при ошибке вызывать Application.Terminate , затем запускать прогу заново(другой прогой) и отрабатывать все снова...
← →
Sergey13 (2003-04-18 09:57) [13]2YDV (17.04.03 13:01)
>SessionID меняется !, но для меня это не проблема
Для тебя да, а для датасета у которого есть свойство Session это видимо проблема. 8-)
> - главное коннект восстановить, ну а потом данные еще разок перечитаем
Ну и нафига тогда огород городить? Перезапустил прогу, перечитал данные. В чем заморочка то?
>проблема в том, что когда связь обывается, ето выцепляю, пытаюсь сделать реконнет и тут: Access violation at address 6139DBED in module "ORA805.dll".Read adress FFFFFFFF.
Вот тут он видимо и пытается сунуться на сервак со старым SessionID и соответственно получает от него.
> но для меня скорей всего придется при ошибке вызывать Application.Terminate , затем запускать прогу заново(другой прогой) и отрабатывать все снова...
Что и требовалось доказать. 8-)
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2003.05.08;
Скачать: [xml.tar.bz2];
Память: 0.48 MB
Время: 0.007 c