Книга: Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil

Специальные возможности FIBPIus

Обработка потери подключения к базе данных

Корректная обработка потери подключения к базе данных является одной из проблем при разработке устойчивых приложений вообще и, пожалуй, самым важным вопросом при разработке приложения, которое будет работать в условиях нестабильного канала связи (в частности, при использовании dial-up).

FIBPIus предоставляет разработчику полный набор средств для обработки потери подключения: возможность аккуратно закрыть все приложение, "закрыть" (т. е. деактивировать все соответствующие компоненты) само подключение на уровне приложения или попробовать восстановить подключение без закрытия запросов.

Ключевым компонентом для обработки ситуации является TpFTBErrorHandler. Формально, потерю подключения мы будем обрабатывать при помощи компонента TpFIBDatabase в обработчике события OnLostConnect, однако без "глубокого" перехвата в TpFIBErrorHandler мы не сможем избавиться от лишних сообщений о потере подсоединения.

Итак, попробуем создать простое приложение, позволяющее редактировать данные в TDBGrid и обрабатывать потерю подключения к базе данных тремя способами, про которые уже было упомянуто (рис. 2.57).

Рис 2.57. Внешний вид главной формы примера Connection Lost

Заполним SelectSQL для CompaniesDataSet: select * from "Companies" и предоставим CompaniesDataSet самостоятельно генерировать модифицирующие запросы (рис. 2.58).

Рис 2.58. Свойства AutoUpdateOptions компонента CompaniesDataSet

Включим также режим CachedUpdates (CompaniesDataSet.CachedUpdates := True), чтобы корректно обрабатывать восстановление подключения без потери данных.

Компонент cmbKindOnLost: TComboBox будет содержать список возможных реакций на потерю подключения, чтобы мы могли во время выполнения приложения попробовать все возможности:

Close pFIBDataBase

Terminate application

Restore connect

Теперь обратим внимание на компонент pFIBErrorHandlerl (рис. 2.59).

TpFIBErrorHandler обрабатывает "особым" образом два типа ошибок: пользовательские исключения и потерю подключения к базе данных. В компонент заложена также возможность обработки ошибок, связанных с нарушением ссылочной целостности, однако в существующих версиях FIBPlus данная функция еще не реализована.

TpFIBErrorHandler имеет только одно событие - OnFIBErrorEvent, обработка которого позволит нам обработать, в частности, потерю подключения к базе данных:

procedure TForml.pFibErrorHandlerlFIBErrorEvent(Sender:

TObject;

ErrorValue: EFIBError; KindlBError: TKindlBError; var

DoRaise: Boolean);

begin

if KindlBError = keLostConnect then begin

DoRaise := false;

Abort;

end;

end;

Puc 2.59. Свойства компонента pFIBErrorHandlerl

Вот в общем-то и весь обработчик - мы просто запрещаем вывод стандартного сообщения о потере подключения. На практике вы сможете использовать OnFIBEnorEvent для более сложной обработки разного рода исключительных ситуаций, используя значение параметра ErrorValue. Для нашего случая важно также знать что, кроме срабатывания QnFIBErrorEvent, TpFIBErrorHandler инициирует возникновение OnLostConnection у компонентов TpFIBDatabase Именно здесь мы и сосредоточим основную обработку потери подсоединения.

procedure TForml.DatabaseLostConnect(Database: TFIBDatabase; E:

EFIBError;

var Actions: TOnLostConnectActions);

begin

AttemptRest := 0;

case cmbKindOnLost.Itemlndex of 0: begin

Actions := laCloseConnect;

MessageDlg('Connection lost. TpFIBDatabase will be closed'',

mtlnformamon, [mbOk] , 0

end;

1: begin

Actions := laTerminateApp;

MessageDlg('Connection lost. Application will be closed',

mtlnformation, [mbOk], 0

end;

2: Actions := laWaitRestore;

end;

end;

Смысл обработчика очевиден - в зависимости от выбранного пользователем значения компонента cmbKindOnLost наше приложение либо "закрывает" активное подключение и все соответствующие компоненты, либо закрывает все приложение, либо включает режим восстановления подсоединения. Первые два случая очевидны и в общем-то не требуют никаких дополнительных шагов, кроме установления значения параметра Actions. Более подробно мы остановимся на восстановлении подключения.

Поскольку CompaniesDataSet находится в режиме CachedUpdates, то потеря подключения не влияет на возможность редактирования данных пользователем, поскольку все изменения будут сохраняться в локальном буфере компонента CompaniesDataSet Таким образом, в задачу TpFIBDataBase входит только одно: периодически пытаться восстано'вить подключение и сообщать об удачных и неудачных попытках. Когда подсоединение будет восстановлено, мы просто применим "отложенные" изменения к данным в базе данных Конечно, никто не гарантирует, что отложенные команды смогут быть выполнены сервером, поскольку на момент восстановления подключения наши локальные данные могут совершенно потерять актуальность.

Итак, напишем два простых обработчика Первый для события Database OnErrorRestoreConnect

procedure TForml.DatabaseErrorRestoreConnect(Database:

TFIBDatabase;

E: EFIBError; var Actions: TOnLostConnectActions);

begin

Inc(AttemptRest);

Label4.Caption := IntToStr(AttemptRest);

Label4.Refresh;

end;

Компонент Label4 будет показывать счетчик попыток восстановления подсоединения. Второе событие, которое нас интересует, - AfterRestoreConnect:

procedure TForml DatabaseAfterRestoreConnect;

begin

MessageDlg('Connection restored. You can apply cached updates',

mtlnformation, [mbOk], 0

) ;

end;

Как только подключение к базе восстановлено, мы получим сообщение и сможем применить все сделанные изменения.

procedure TForml.ButtonlClick(Sender: TObject);

begin

with CompaniesDataSet do

try

if not DataBase.Connected then begin

try

DataBase.Connected . = True;

except

MessageDlg('Can''t restore connect',

mtlnformation, [mbOk], 0

Exit;

end

end;

if not Transaction.Active then Transaction StartTransaction;

ApplyUpdToBase;

Transaction.CoimutRetaining;

CommitUpdToCach;

except

if Transaction.Active then Transaction.RollBack;

end;

end;

На практике вы можете автоматически вызывать процедуру применения данных сразу из обработчика AfterRestoreConnect. В самой процедуре следует обратить внимание на методы ApplyUpdToBase и CommitUpdToCach. В отличие от стандартного метода ApplyUpdates, наследованного от TDataSet, который "не замечает" скрытые в результате локальной фильтрации записи (более подробно этот вопрос будет рассмотрен в разделе "Локальная фильтрация"), методы ApplyUpdToBase и CommitUpdToCach позволяют обойти эту ошибку VCL

Оглавление книги