Приложения DSQL используют вызовы API для прослушивания событий как синхронных, так и асинхронных. В DSQL не существует для них эквивалентов, а установка для интерфейсов приложений сырых составных частей является довольно сложной.

Приложение регистрирует интерес в событиях с помощью буфера параметров событий (Events Parameter Buffer, EPB), который заполняется при вызове функции isc_event_block. Один EPB может регистрировать не более 15 событий, задавая различные EPB и список событий для каждого вызова. Именованные события должны соответствовать (с учетом регистра) событиям, которые будут отправлены. Приложения, которым нужно отвечать более чем на 15 событий, могут выполнить несколько вызовов isc_event_block.

Установка синхронного прослушивания через API похожа на то, что вы должны сделать для асинхронной сигнализации за исключением того, что при этом вызывается

функция isc_wait_for_event вместо isc_que_event. Как и в случае с эквивалентом в ESQL, EVENT WAIT, выполнение программы приостанавливается на время ожидания. Функция isc_wait_for_event прослушивает оповещение, которое появится, когда сервер выполнит функцию обратного вызова.

Прежде чем вы сможете использовать функцию сигнализации API isc_que_evento, вам нужно выполнить функцию обратного вызова на клиенте, которую вызывал бы сервер при посылке события. Названием для такого типа функции является асинхронный перехват, или AST.

Функция AST предоставляет некоторую форму глобальных флагов для оповещения приложения, когда к нему обращается сервер. Она обрабатывает список событий сервера в буферах, к которым приложение может иметь доступ при управлении собственной очередью событий. Функция должна получать три аргумента:

* копию списка отправленных событий;

* длину буфера events_list;

* указатель на буфер events_iist.

Документ InterBase API Guide [128] содержит рекомендации по написанию функций AST.

Функция isc_event_biock принимает в своем параметре isc caiiback указатель на функцию AST и в своем параметре event_function_arg- указатель на первый аргумент AST. Этот аргумент обычно получает значение счетчика событий, когда они изменяются.

Когда приложение вызывает функцию isc_que_events о для сообщения о событиях, которые оно будет ожидать, оно передает вместе со списком указатель на функцию обратного вызова AST. Один вызов isc_que_events может содержать до 15 событий. Приложение вызывает функцию isc_event_counts для определения того, какое событие произошло.

Множество вызовов isc que eventso может выполняться одновременно в одном процессе клиент-сервер. Приложения отключают режим ожидания при вызове функции isc_cancel_events.

! ! !

ПРИМЕЧАНИЕ. Подробности установки блока событий для синхронного прослушивания через isc_event_wait такие же. События не являются постоянными, как при асинхронной технике isc_que_events. Синхронная сигнализация не требует внешней функции AST.

. ! .

К счастью, почти для всех из нас фрагменты кодов для реализации событий в клиентских приложениях инкапсулированы в классах и компонентах в большинстве инструментов разработки приложений, которые поддерживают Firebird. Такие компоненты, включающие в себя AST, инкапсулирующие вызовы функций API isc_event* вместе с блоками параметров событий и управление буферами событий на клиентской стороне, обычно называются обработчиками сообщений (event alerter). Иногда этот термин в форумах и литературе вызывает путаницу, потому что триггеры и хранимые процедуры, вызывающие POST_EVENT, также часто называют обработчиками сообщений.

Для использования обработчика сообщений в хранимой процедуре или триггере применяйте следующий синтаксис:

POST_EVENT <имя-события>;

Параметр <имя-события> может быть или литералом в кавычках, или строковой переменной. Он является чувствительным к регистру и может начинаться с цифры. Имена событий ограничиваются 64 символами.

При выполнении процедуры этот оператор сообщает о событии менеджеру событий, который сохраняет его в таблице событий. При подтверждении транзакции менеджер событий информирует приложения, ожидающие это событие. Например, следующий оператор посылает событие с именем new_order:

POST_EVENT ' new_order' ;

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

POST EVENT event name;

! ! !

ПРИМЕЧАНИЕ. Хотя POST_EVENT и является оператором SQL, его аргумент имя события не должен иметь префикс двоеточия.

. ! .

Триггер или хранимая процедура, которые посылают сообщение, иногда называются обработчиками сообщений [129] . Следующий скрипт создает триггер, который посылает событие менеджеру событий, когда любое приложение добавляет в таблицу данные: