Автоматическое восстановление, когда общая сетевая ошибка Dbnetlib ConnectionWrite приводит к отключению соединений ADO в приложениях Delphi?

Googling это сообщение об ошибке ADO указывает, что оно обычно встречается в ASP.NET разработка, но я не нашел много упоминаний о том, когда это происходит в приложениях Delphi. У нас есть некоторые сайты клиентов, которые испытывают временные проблемы с сетью, и это симптоматическое сообщение об ошибке. Мы можем легко дублировать его в office testing; просто закройте службу MS SQL Server, пока ваш объект delphi TADOConnection подключен к базе данных на этом экземпляре сервера, и вы получите это исключение:

   [DBNETLIB][ConnectionWrite (send()).]General network error. Check your network documentation.

Да, поймать это исключение, и вы знаете (или вы?), что эта ошибка произошла. За исключением того, что это приложение 800 KLOC+ с более чем 10,000 try-кроме блоков вокруг действий базы данных, любой из которых может потерпеть неудачу с этой ошибкой.

TADOConnection имеет некоторые события ошибок, ни один из которых не срабатывает в этом случае. Тем не менее само соединение ADO неисправен, как только это происходит, даже при перезапуске базы данных SQL, TADOConnection.Соединенные остатки верно, но это ложь. Он действительно в неисправном состоянии.

Итак, мой вопрос:

можете ли вы обнаружить это неисправное состояние и восстановить из него каким-либо образом, что меньше работы, чем в 10 000 отдельных попыток, кроме блоков и установки некоторой глобальной "повторно подключить глобальную переменную ADO"?

Я надеюсь, что есть способ войти в TADOConnection.ConnectionObject (базовый необработанный объект OLEDB COM ADO) и обнаружить это условие неисправности существует, когда мы запускаем новый запрос, так что мы можем сбросить ADOConnection и продолжить при следующем запуске запроса. Поскольку наш код организован таким образом, что позволил бы нам обнаружить это "после сбоя" гораздо легче, чем это позволило бы нам сделать это так, как я бы сделал это в демонстрационном приложении 10 line.

это другой так вопрос спрашивает, почему это происходит, то есть не то, что я прошу, пожалуйста, не дай мне "предупреждение" ответы, я уже знаю о них, я ищу метод восстановления и обнаружения застопорившихся ADO-соединений, кроме ловли исключений. На самом деле, это хороший пример неправильных исключений; ADO-объект schrodingers-cat в этом режиме сбоя.

Я знаю о статьях базы знаний MS и различных решениях, плавающих по интернету. Я спрашиваю о восстановлении без потери данных клиента, как только условие ошибки (которое часто является переходным в нашем ситуация) прояснилась. Это означает, что мы замораживаем наше приложение, показываем исключение клиенту, и когда клиент нажимает повторить или продолжить, мы пытаемся восстановить и продолжить. обратите внимание, что наш существующий код делает миллион try-except-log-and-continue кода, который будет мешать нам, поэтому я ожидаю, что кто-то ответит, что обработчик приложений для необработанных исключений-лучший способ, но, к сожалению, мы не можем его использовать. Я действительно надеюсь, однако, что можно обнаружить замороженный / неисправный / мертвый ADO объект подключения.

вот что у меня есть:

try
  if fQueryEnable and ADOConnection1.Connected then begin
    qQueryTest1.Active := false;
    qQueryTest1.Active := true;
    Inc(FQryCounter);
    Label2.Caption := IntToStr(qQueryTest1.RecordCount)+' records';

  end;
except
      on E:Exception do begin
         fQueryEnable := false;
         Memo1.Lines.Add(E.ClassName+' '+E.Message);
         if E is EOleException and Pos('DBNETLIB',E.Message)>0 then begin
            ADOConnectionFaulted := boolean; { Global variable. }
         end;
         raise;
      end;
end;

проблема с вышеуказанным решением заключается в том, что мне нужно скопировать и вставить его около 10 000 мест в моем приложении.