Smile |
Отправлено: 12.05.2004, 14:22 |
|
Ученик-кочегар
Группа: Участник
Сообщений: 13
|
Необходимо проверить состояние TADOConnection в run-time по событию какого-нибудь таймера. С помощью каких свойств и методов можно проверить состояние соединения с БД. Проблема: открыл соединение и выдернул сетевой кабель, а состояние соединения не изменяется. Не хочется каждый раз делать Close() и Open() для проверки соединения через каждую 1 сек. Может есть в TADOConnection какие-нибудь свойства для проверки реального состояния соединения??? |
|
Gedeon |
Отправлено: 12.05.2004, 15:20 |
|
Ветеран
Группа: Модератор
Сообщений: 1742
|
Да, вопрос конечно интересный, стандартными методами TADOConnection никак, можно пробовать переходить на 1 запись вперед назад на каком-то DataSet, или вообще пинговать сервер(что по моему лучше всего).
|
|
olegenty |
Отправлено: 12.05.2004, 15:26 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
блин, да фигня всё это, просто try... catch(...) пользоваться надо, и о сообщениях об ошибках поподробнее почитать... (конкретно для ADO специфичных)
|
|
Gedeon |
Отправлено: 12.05.2004, 15:40 |
|
Ветеран
Группа: Модератор
Сообщений: 1742
|
QUOTE (olegenty @ 12/05/2004, 16:28) | блин, да фигня всё это, просто try... catch(...) пользоваться надо, и о сообщениях об ошибках поподробнее почитать... (конкретно для ADO специфичных) |
Если необходимо реализовать безошибочную работу приложения, то безусловно все завернуть в try... catch(...) и отлавливать ошибки аля ADO Connection Failed, а если явно хочется показывать индикатор соединения аля MSSQLServer в tray, тогда физическую связь проверять пингом, а по поводу работы сервера читать доку по каждому конкретному. Если БД — файл то FileExists();
|
|
Smile |
Отправлено: 12.05.2004, 15:57 |
|
Ученик-кочегар
Группа: Участник
Сообщений: 13
|
QUOTE (olegenty @ 12/05/2004, 16:28) | блин, да фигня всё это, просто try... catch(...) пользоваться надо, и о сообщениях об ошибках поподробнее почитать... (конкретно для ADO специфичных) |
Ну да, короче я понял, что вы не знаете как с помощью свойств TADOConnection проверить состояние соединения, т.к. я вообще-то использую try...catch, но надеялся, что можно проще, чтобы постоянно не юзать хранимую процедуру. Но видимо, выхода нет, придется так и оставить. Но проверка задалбывает — каждую секунду! |
|
Gedeon |
Отправлено: 12.05.2004, 16:39 |
|
Ветеран
Группа: Модератор
Сообщений: 1742
|
В ответ на предыдущий пост и личное сообщение:
Во первых пинг-идеальное, встроенное в систему средство проверки физического соединения с удаленным компом, работает очень бысто в LAN < 10 ms. Дальше проверка каждую секунду просто бессмысленна т.к. есть такое понятие как ConnectionTimeOut, которое из хэлпа: The default value is 15 seconds. При обрыве связи Вы просто херней страдаете выполняя проверку каждую секунду. Дальше на 3 базах делать пустую хранимую процедуру тоже бессмысленно т.к. сервер м.б. либо остановлен либо нет, проверить достаточно только в одной, если какая-то база м.б. удалена, так извините — это администрить нормально надо. . Кроме того проверка работы сервера выполняется стандартным методом проверки работы службы, для этого надо иметь соответствующие права. Иконка которую видно в трэе показывает эту работу, запрос осуществляется каждые 4 секунды (Е.Мамаев SQL Server 2000), мелкософт такую цифру наверное не с потолка взял, наверняка была проанализирована куча инфы для такого выбора.
|
|
Smile |
Отправлено: 12.05.2004, 17:11 |
|
Ученик-кочегар
Группа: Участник
Сообщений: 13
|
QUOTE (Gedeon @ 12/05/2004, 17:41) | В ответ на предыдущий пост и личное сообщение:
Во первых пинг-идеальное, встроенное в систему средство проверки физического соединения с удаленным компом, работает очень бысто в LAN < 10 ms. Дальше проверка каждую секунду просто бессмысленна т.к. есть такое понятие как ConnectionTimeOut, которое из хэлпа: The default value is 15 seconds. При обрыве связи Вы просто херней страдаете выполняя проверку каждую секунду. Дальше на 3 базах делать пустую хранимую процедуру тоже бессмысленно т.к. сервер м.б. либо остановлен либо нет, проверить достаточно только в одной, если какая-то база м.б. удалена, так извините — это администрить нормально надо. . Кроме того проверка работы сервера выполняется стандартным методом проверки работы службы, для этого надо иметь соответствующие права. Иконка которую видно в трэе показывает эту работу, запрос осуществляется каждые 4 секунды (Е.Мамаев SQL Server 2000), мелкософт такую цифру наверное не с потолка взял, наверняка была проанализирована куча инфы для такого выбора. |
Да, я пониманию, что херней, но так надо, при малейшем не стабилном сооединении нужно вести лог! Да, можно было поставить таймер на 15 сек, но нужно, как наиболее поменьше интервал обновления ставить. Требования такие! |
|
Gedeon |
Отправлено: 13.05.2004, 08:51 |
|
Ветеран
Группа: Модератор
Сообщений: 1742
|
Ну что вы сами себя обманываете? Каждую секунду такую проверку просто нереально делать. Во первых в ваших условиях отказываться от пинга просто не разумно, не знаю как у вас, но везде где я сталкивался с SQL Server, в соединении самое узкое место — физическая связь. Пинг в лэн может для проверки занять максимум 50 мс, это время определяет его таймаут, плюс в логе вы получаете причину отказа в соединении, а не только его факт. Нет связи виноваты одни, стал сервер — другие. Проверку работы сервера делайте методом проверки работы службы SQLServer, причем быстрее 4 секунд вы этого не сделаете. Обратной стороной является запись в лог каждого удачного выполнения коннэкта, автоматически неответ сервера является ошибкой. Не хотите проверять службу, установите ConnectionTimeOut секунд в 5, киньте на форму связанный с ним TADOQuery, выполняющий простейший запрос(аля SELECT GETDATE()) и делайте ему ReQuery, да еще и дату со временем получите. Пробуйте уменьшать время ConnectionTimeOut в зависимости от вашего сервера и сети можно приблизиться к очень малому времени. Само собой ReQuery оберните в try... catch(...) и отлавливайте ошибку соединения.
Итак на мой взгляд алгоритм видится следующий: Через определенный интервал времени начало проверки
1) пинг тачки с сервером, ответ хорошо, неответ в лог пишем сетевики-подонки;
2) проверка собственно самого сервера, ответ хорошо, неответ в лог админ сейчас приедет на работу.
|
|
|