Можно ли в ADO или OLEDB проверить реальное состояние коннекта ? Не делая пробных действий типа выполнения коротких запросов и т.д.
Насколько я знаю, в DBLibrary есть функция dbdead - вот хотелось бы ее аналог найти.

Среди возможных вариантов состояния коннекта нет понятия "invalid".
adStateClosed
adStateOpen
adStateConnecting
adStateExecuting
adStateFetching
Так вот, если коннекция была открыта нормально, а потом что-то случилось с сервером - застопили сиквел, нарушена физическая связь с машиной, где стоит сиквел и т.д., то состояние как было adStateOpen, так и останется.

2 SergSuper: честно говоря, я не знаю, как работает dbdead Мне про нее просто сказал человек, который писал на dblibrary, так что Ваше сообщение очень интересно.
2 skv@analyst.ru: спасибо, поищу, почитаю...
2 Genady: проблема выглядит вот как. В программе есть несколько SQL коннектов с длительным временем жизни. Если в какой-то момент происходит ошибка, то надо коннект закрыть/открыть и попробовать повторить операцию. Вопрос в том, кто будет осознавать, какая именно ошибка произошла - то ли это неправильный сиквельный запрос (неверный синтаксис, неправильные данные, key violation и т.д.), то ли это коммуникационная ошибка. В первом случае коннект трогать не надо, во втором - надо. Разделение ошибок по кодам - вещь весьма сомнительная. Хотелось бы иметь возможность понять, что виноват не запрос, а коннект. Поскольку объекты имеют большую длительность жизни, то web-подход "получил коннект, выполнил операцию, отвалился" здесь не прокатывает. И еще - в программе наряду с выполнением пользовательских запросов идут фоновые операции в отдельных потоках. Они тоже имеют свои коннекты и пользуются ими постоянно. В этом случае также хотелось бы уметь осознать, что связь порвалась и через некоторое время попробовать ее восстановить.
Примерно так. Если что-то непонятно написано или надо поподробнее - скажите, я напишу.

Гм. Я вот насчет разделения ошибок. Дохлый коннект - когда недоступен сервер физически, когда нет такой базы (ну вот долбанули ее, или она сейчас в single mode, или suspend, или права доступа для логина поменяли, или ...) - короче, много вариантов наклевывается с многими кодами ошибок. Мне не хочется ЯВНО прописывать их в здоровенном switch - может, я ошибаюсь, но это порочный путь.
Возможно, я остановлюсь на следующем способе - при анализировании error в коллекции пришедших ошибок смотреть, какой объект является инициатором. Если Connection, то сразу считать, что коннект протух и переходить к close/open, если Command, то это нормально и коннект не трогать. Вот еще подумаю немного...