Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

Когда приложение вызывает функцию 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

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

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

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

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

POST_EVENT ' new_order' ;

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

POST EVENT event name;

! ! !

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

. ! .

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

SET TERM А;

CREATE TRIGGER POST_NEW_ORDER FOR SALES ACTIVE AFTER INSERT POSITION 0

AS

BEGIN

POST_EVENT 'new_order'; END ^

SET TERM ; ^

Триггер или процедура?

Оператор POST EVENT доступен и в триггерах, и в хранимых процедурах. Как же решить, где лучше его поместить для посылки событий?

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

Это только общие соображения - часто процедуры имеют область действия на уровне строки, и если заинтересованные клиенты хотят знать, когда произошла конкретная операция, событие посылается в такой хранимой процедуре. В этом случае POST_EVENT в триггере не будет иметь возможности ничего сообщить приложениям о контексте события. Разработчик может использовать события в процедуре, чтобы установить, какое приложение ответственно за выполнение соответствующей работы. В другом варианте разработчик может поместить сообщение о событии в триггер, чтобы гарантировать, что конкретное действие DML будет информировать всех, независимо от контекста, в котором оно выполняется.

Пора дальше

Теперь мы обратимся к безопасности вашего сетевого окружения СУБД. В этой части мы рассмотрим риски и меры безопасности, связанные с выполнением ваших серверов баз данных Firebird. Для начала в следующей главе обсуждаются некоторые слабые места в системе защиты операционного окружения и меры, которые вы можете принять по их устранению.

ЧАСТЬ VIII. Безопасность.

ГЛАВА 33. Безопасность в операционной среде.

В Firebird не существует средств для шифрования и дешифрования данных (кроме паролей пользователей), которые передаются через клиентский интерфейс. Существуют некоторые ограничения в использовании инструментов Firebird, которые осуществляют доступ к базам данных, но, в конечном счете, на уровне программного обеспечения нет защиты от налетчиков, которые установили доступ к вашей базе данных без авторизации.