Как грамотно восстанавливать подключение к БД при обрыве связи?
Взаимодействие идет через ADO. Если в процессе работы (подключение уже было установлено) возникает обрыв связи с БД, то естественно, при попытке обращения к ней получаем ошибку. После того как соединение восстановилось, у обьекта connection вызываем Close, потом Open, но это не помогает. Хотя сами эты вызовы выполняются без ошибок, при попытке запроса к базе все равно получаем ошибку. Помогает только удаление объекта и создание нового.
А если в программе используется несколько одновременных подключений, то необходимо их ВСЕ уничтожить и создать заново. Но это не удобно при работе, т.к. подключения реализованы в разных модулях и различных потоках. т.е. достаточно сложно это все синхронизировать вместе.
Может есть еще способы восстановить подключения?

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

K>После того как соединение восстановилось, у обьекта connection вызываем Close, потом Open, но это не помогает. Хотя сами эты вызовы выполняются без ошибок, при попытке запроса к базе все равно получаем ошибку. Помогает только удаление объекта и создание нового.

Попробуй указать в строке подключения "OLE DB Services=0"

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

K>Как грамотно восстанавливать подключение к БД при обрыве связи?
K>Взаимодействие идет через ADO. Если в процессе работы (подключение уже было установлено) возникает обрыв связи с БД, то естественно, при попытке обращения к ней получаем ошибку. После того как соединение восстановилось, у обьекта connection вызываем Close, потом Open, но это не помогает. Хотя сами эты вызовы выполняются без ошибок, при попытке запроса к базе все равно получаем ошибку. Помогает только удаление объекта и создание нового.
K>А если в программе используется несколько одновременных подключений, то необходимо их ВСЕ уничтожить и создать заново. Но это не удобно при работе, т.к. подключения реализованы в разных модулях и различных потоках. т.е. достаточно сложно это все синхронизировать вместе.
K>Может есть еще способы восстановить подключения?

1. Отключаем пуллинг — OLE DB Services = -2
2. Обрабатываем (пример на дельфе): как обработать разрыв связи ADO с б.д.

КД>Попробуй указать в строке подключения "OLE DB Services=0"

Спасибо! работает. но теперь другой вопрос. Этой строкой мы отключаем пул соединений, а их, как я говорил, у меня много. т.е. отключать сам пул не желательно. Производительность упадет. Можно решить эту задачу с сохранением пула соединений? Как сам пул восстановить?

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

КД>>Попробуй указать в строке подключения "OLE DB Services=0"

K>Спасибо! работает. но теперь другой вопрос. Этой строкой мы отключаем пул соединений, а их, как я говорил, у меня много. т.е. отключать сам пул не желательно. Производительность упадет. Можно решить эту задачу с сохранением пула соединений? Как сам пул восстановить?

Ты с каким сервером баз данных работаешь?

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Ты с каким сервером баз данных работаешь?

Тестирую на Sybase SQL 5.5 и MS SQL 2000. Но вообще хотелось бы универсальности

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

K>Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>>Ты с каким сервером баз данных работаешь?

K>Тестирую на Sybase SQL 5.5 и MS SQL 2000. Но вообще хотелось бы универсальности

Да я так, вообщем, спросил. В задумчивости.

Пул, когда возвращает объект подключения, дергает свойство "Reset DataSource" (набор свойств "Data Source")

Это свойство (да и вообще — все наборы, кроме группы свойств инициализации) доступны только для инициализированного источника.

То есть, пул пытается дернуть свойство, провайдер возвращает ошибку "свойство не поддерживается", пул считает что провайдер это свойство вообще не поддерживает.

Ему же не вдамек, что источник не инициализирован (потерял подключение)....

.... Кстати, в IBProvider-е сделан "хак" который дает дернуть это свойство для неинициализированного источника, в этом случае он честно сообщает — "Источник не инициализирован, повторное использование не возможно". Как раз для решения случаев, подобных твоему.

Так что есть предложение.

Делаешь COM-объект, который будет аггрегировать OLEDB провайдеры и замещать интерфейс IDBProperties. Замещаешь метод SetProperties, и отлавливаешь установку свойства DBPROP_RESETDATASOURCE. Ну и рулишь по-ситуации

Вызовы остальных методов интерфейса IDBProperties напрямую транслируешь в провайдер

Вообщем, работы на час-полтора

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Так что есть предложение.

КД>Делаешь COM-объект, который будет аггрегировать OLEDB провайдеры и замещать интерфейс IDBProperties. Замещаешь метод SetProperties, и отлавливаешь установку свойства DBPROP_RESETDATASOURCE. Ну и рулишь по-ситуации

КД>Вызовы остальных методов интерфейса IDBProperties напрямую транслируешь в провайдер

КД>Вообщем, работы на час-полтора

Спасибо. буду разбираться
А неужели нет нормального, готового способа восстановление подключения в данном случае? Ведь отказоустойчивость — актуальная задача любой БД и не только. А это типичный случай для сетевых БД...

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

K>А неужели нет нормального, готового способа восстановление подключения в данном случае? Ведь отказоустойчивость — актуальная задача любой БД и не только. А это типичный случай для сетевых БД...



Вообще говоря, у провайдеров есть два свойства
— Упомянутое "Reset Datasource", которое используется пулом для сброса состояния подключения перед повторным использованием
— И "Connection Status" — это информационное свойство, используемое для проверки состояния источника данных.

Оба эти свойства доступны только для инициализированного (и, возможно, потерявшего подключение) источника данных.

То есть, если провайдер решил, что он неиницализирован — эти свойства будут не доступны. И это, на мой взгляд — это бага в спецификации OLEDB.