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

Рис 2.68. Использование локальной фильтрации TpFIBDataSet

Совершенно очевиден код для подключения к базе данных. Список элементов компонента FieldsC: TComboBox заполняется названиями полей из таблицы BIOLIFE.

FilteringDS.SelectSQL: SELECT * FROM BIOLIFE

procedure TMainForm.btnConnectClickfSender: TObject);

var Index: Integer;

begin

with MainDB do begin

ConnectParams.UserName := edtUserName.Text;

ConnectParams.Password := edtPassword.Text;

DBName := edtDataBase.Text;

try

Open;

FilteredDS.Open;

FieldsC.Items.Clear;

for Index := 0 to pred(FilteredDS.FieldCount) do

FieldsC.Items.Add(FilteredDS.Fields[Index].FieldName);

except

MessageDlgt'Error of connection to a database!', mtError, [mbOk], 0) ;

Close;

end;

end;

end;

Пользователь может выбрать поле из списка FieldsC, указать в поле FilterE: TEdit строку для поиска и после нажатия на кнопку Button I ("Activate Filter"):

procedure TMainForm.ButtonlClick(Sender: T0b3ect);

begin

FilteredDS.Filtered := false;

FilteredDS.Filtered := true;

end;

в DBGrid 1 останутся видны только те записи, которые содержат в заданном поле искомую строку Для этого нам необходимо написать обработчик события OnFilterRecord у FilteringDS:

procedure TMainForm.FilteredDSFilterRecord(DataSet: TDataSet;

var Accept: Boolean); begin

Accept := DOS(FilterE.Text,

FilteredDS.FieldByName(FieldsC.Text).AsString) <> 0

end;

После включения FilteredDS.Filtered := true OnFilterRecord вызывается для каждой записи в локальном буфере. Если мы хотим, чтобы конкретная запись оставалась видимой, мы должны задать для нее параметр Accept равным True. Из примера кода видно, что мы оставляем видными только те записи, которые содержат в искомом поле (FieldsC.Text) заданную строку (FilterE.Text). Если мы, например, выберем поле COMMON_NAME и укажем строку для поиска "А", то в результате получим только две видимые записи (рис. 2.69).

Рис 2.69. Пример двух "отфильтрованных" записей

Поскольку наше условие для фильтра сформулировано таким образом, что мы выбираем записи по точному включению искомой подстроки - в нашем случае это только те записи, которые содержат большую букву "А". Мы можем немного усложнить условие поиска. Положим на форму CaseC: TcheckBox (см. рис. 2.69, "Case sensitive") и перепишем обработчик OnFilterRecord следующим образом:

procedure TMainForm.FilteredDSFilterRecord(DataSet: TDataSet;

var Accept: Boolean);

begin

if CaseC.Checked then

Accept := pos(FilterE.Text,

FilteredDS.FieldByName(FieldsC.Text).AsString) <> 0

else

Accept := pos(AnsiUpperCase(FilterE.Text),

AnsiUpperCase(FilteredDS.FieldByName(FieldsC.Text).AsString))

<> 0;

end;

Очевидно, что теперь если пользователь отключит "флажок" "Case sensitive", то фильтр по строке "А" будет содержать гораздо большее количество записей - все записи, которые содержат хотя бы одну букву "А", неважно маленькую или большую (рис. 2.70).

Рис 2.70. Записи, содержащие букву "А"

Очевидно, что использование локальной фильтрации дает разработчику в руки очень гибкое средство построения условий, поскольку этот механизм не столько ограничен, как SQL в условиях WHERE. На основе локальной фильтрации, например, очень легко создается механизм быстрого поиска записи по первым буквам, которые пользователь набирает в поле редактирования.

Обработка событий InterBase при помощи FIBPIus

InterBase дает разработчику некоторый механизм для синхронизации приложений в многопользовательской среде Event Alerts. Суть данного механизма состоит в том. что вы можете вызывать пользовательские события из триггеров или хранимых процедур при помощи функции POST_EVENT:

CREATE PROCEDURE SHOW_EVENT(

EVENT_ID INTEGER)

AS

BEGIN

IF (:EVENT_ID = 1) THEN POST_EVENT 'TEST_EVENT1';

IF (.EVENT_ID = 2) THEN POST_EVENT 'TEST_EVENT2';

IF (.EVENT_ID = 3) THEN POST_EVENT 'TEST_EVENT3';

EXIT;

END

Создадим приложение (рис 2.71), которое будет вызывать данную процедуру и получать соответствующие события Если вы впоследствии попробуете запустить это приложение на двух компьютерах, то оба приложения будут получать сообщения вне зависимости оттого, кто их инициировал

Рис 2.71. Использование InterBase events, при помощи компонента TSIBfibEventAlerter

Для вызова хранимой процедуры мы будем использовать специальный компонент pFIBStoiedPioc TpFIBStoredPioc, задав свойство StoiedProcName (рис 2.72)

Рис 2.72. Вызов хранимой процедуры при помощи компонента TpFIBStoredPioc

Компонент TpFIBStoredProc является прямым потомком TpFIBQuery и сам формирует свойство SQL в виде ' EXECUTE PROCEDURE ...' Название процедуры задается свойством StoiedProcName

Компонент SffifibEventAlerterl: TSffifibEventAlerterlпредназначен для получения приложением событий InterBase Компонент ссылается на конкретное подключение к базе данных, т.е. на компонент типа TpFIBDatabase (рис 2.73)

Рис 2.73. Свойства SIBfibEventAlerterl

Установим свойство AutoRegister в False, чтобы собственноручно зарегистрировать нужные нам события, а в свойстве Events перечислим те события, которые нас интересуют (рис. 2.74).

Рис 2.74. Список зарегистрированных событий

Чтобы компонент SIBfibEventAlerterl "получал" события, мы должны зарегистрировать их после подключения к базе данных. Для этого напишем обработчик события OnConnect у компонента pFIBDatabasel:

procedure TForml.pFIBDatabaselConnect(Sender: TObject);

begin

if not SIBfibEventAlerterl.Registered then

SIBfibEventAlerterl.RegisterEvents;

end;

Соответственно перед закрытием подключения желательно "отключить" SIBfibEventAlerterl. Для этого создадим обработчик события BeforeDisconnect компонента pFIBDatabasel:

procedure TForml.pFIBDatabaselBeforeDisconnect(Sender:

TObject);

begin

if SIBfibEventAlerterl.Registered then

SIBfibEventAlerterl.UnRegisterEvents;

end;

Зададим свойство Tag у кнопок равным соответственно 1, 2 и 3, и напишем общий обработчик события OnClick для них:

procedure TForml.ButtonsClick(Sender: TObject);

begin

if not pFIBTransactionl.InTransaction then

pFIBTransactionl.StartTransaction;

pFIBStoredProcl.Params[0].Aslnteger := TButton(Sender).Tag;

try

pFIBStoredProcl.ExecProc;

pFIBTransactionl.Commit;

except

pFIBTransactionl.Rollback;

end;

end;

Смысл кода очевиден - мы задаем значение параметра процедуры, используя свойство Tag у кнопки, на которую нажал пользователь, выполняем процедуру при помощи метода ExecProc и либо подтверждаем транзакцию, либо отменяем ее в случае ошибки. Нам остается только написать обработчик события OnEventAlert компонента SIBfibEventAlerterl:

procedure TForml . SIBf ibEvent Alerter 1 Event Alert (Sender : TObject ;

EventName: String, EventCount: Integer);

begin

ShowMessage(EventName + ' : ' + IntToStr(EventCount));

end;

Параметр EventName возвращает название произошедшего события, a EventCount возвращает количество событий EventName. Значение параметра EventCount требует некоторых разъяснений. Итак, при работе с событиями важно помнить, что реально они вызываются только в случае подтверждения транзакции. Иными словами, если вы вызываете некоторое событие 'NEW_CUSTOMER' при вставке записей в таблицу, и вызываете Commit только после вставки 1000 записей, то обработчик OnEventAlert будет вызван только один раз, сразу после Commit, и значение параметра EventCount будет равно 1000. Очевидно, что событие произошло 1000 раз, но приложение получает нотификацию обо всех событиях только после подтверждения транзакции, в контексте которой они происходили.

Мы можем запустить наше приложение. При нажатии на любую из кнопок мы будем получать сообщение о произошедшем событии, причем, как уже было сказано, если наше приложение запущено несколько раз и даже на разных компьютерах, все копии приложения будут получать нотификацию о событиях.

"Низкоуровневая" работа с внутренним буфером TpFIBDataSet

TpFIBDataSet включает несколько специальных методов для работы с внутренним буфером, в котором хранятся записи. В общем-то, данные методы превращают TpFIBDataSet в аналог TClientDataSet, ориентированный на InterBase. Наиболее интересным примером использования данных методов будет, пожалуй, построение диалога выбора, состоящего из двух списков (рис. 2.75).

Рис 2.75. Использование локального кеша TpFIBDataSet для организации двойного списка выбора

В данном примере мы будем использовать базу данных EMPLOYEE.GDB, входящую в стандартную поставку InterBase и FIBPlus. Покажем запросы для SourceDS:

SelectSQL:

SELECT

CUS.CUST_NO,

CUS.CUSTOMER

FROM

CUSTOMER CUS

ORDER BY CUS.CUSTOMER

UpdateSQL:

UPDATE CUSTOMER SET

CUSTOMER = ?CUSTOMER

WHERE

CUST_NO = ?OLD_CUST_NO

InsertSQL:

INSERT INTO CUSTOMER(

CUST_NO,

CUSTOMER

)

VALUES(

?CUST_NO,

?CUSTOMER

)

DeleteSQL:

DELETE FROM CUSTOMER

WHERE

CUST_NO = ?OLD_CUST_NO

RefreshSQL:

SELECT

CUS.CUST_NO,

CUS.CUSTOMER

FROM

CUSTOMER CUS

WHERE

(

CUS.CUST_NO = ?OLD_CUST_NO

)

Те же самые запросы мы будем использовать в TargetDS, поскольку оба компонента должны обладать совместимой структурой полей. Откроем оба запроса сразу после создания формы:

procedure TDualListForm.FormCreate(Sender: TObject);

begin

SourceDS.Open;

TargetDS.CacheOpen;

end;

Если мы не указываем в коде явного открытия базы данных, то это означает, что свойство Connected > компонета TpFlBDatabase было задано в True в design-time.

Обратите внимание на то, что TargetDS мы активируем при помощи специального метода CacheOpen. Этот метод не выполняет запрос из SelectSQL, а только подготавливает внутренний буфер компонента в зависимости от запроса в SelectSQL. Очевидно, что после запуска приложения мы увидим записи в левом списке и пустую таблицу в правом. Теперь мы можем написать процедуру, которая позволит переносить записи из одного списка в другой: