Використання post_event

Розглянуто питання, необхідні розробнику для створення клієнт-серверних додатків з використанням СУБД Firebird, що стала розвитком СУБД Borland Interbase 6. Утримується огляд концепцій і моделей архітектури клієнт / сервер, а також практичні рекомендації по роботі з клієнтськими бібліотеками Firebird. Детально описані особливості типів даних SQL, мова маніпулювання даними (Data Manipulation Language, DML), а також синтаксис і оператори мови визначення даних (Data Definition Language, DDL). Велика увага приділена опису транзакцій і наведено поради щодо їх використання при розробці додатків. Описано програмування на стороні клієнта і сервера написання тригерів і збережених процедур, створення і використання подій бази даних, обробка помилок в коді на сервері і багато іншого. Матеріал супроводжується численними прикладами, порадами та практичними рекомендаціями.

Для розробників баз даних

Книга: Firebird КЕРІВНИЦТВО РОЗРОБНИКА БАЗ ДАНИХ

Використання POST_EVENT

Розділи на цій сторінці:

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

параметр <имя-события> може бути або літералом в лапках, або строкової змінної. Він є чутливим до регістру і може починатися з цифри. Імена подій обмежуються 64 символами.

При виконанні процедури цей оператор повідомляє про подію менеджеру подій, який зберігає його в таблиці подій. При підтвердженні транзакції менеджер подій інформує додатки, які очікують цю подію. Наприклад, наступний оператор надсилає подія з ім'ям new_order:

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

POST EVENT event name;

ПРИМІТКА. Хоча POST_EVENT і є оператором SQL, його аргумент ім'я події не повинен мати префікс двокрапки.

Тригер або збережена процедура, які посилають повідомлення, іноді називаються обработчиками повідомлень [129]. Наступний скрипт створює тригер, який посилає подія менеджеру подій, коли будь-який додаток додає в таблицю дані:

CREATE TRIGGER POST_NEW_ORDER FOR SALES ACTIVE AFTER INSERT POSITION 0

POST_EVENT 'new_order'; END ^

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

Оператор POST EVENT доступний і в тригерах, і в збережених процедурах. Як же вирішити, де краще його помістити для посилки подій?

Емпіричним правилом є використання тригерів, коли додатків потрібно знати про події на рівні рядка - одного рядка або безлічі рядків, в залежності від області дії транзакції, - і процедур для сигналізації про такі події, які впливають на додатки в цілому.

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

пора далі

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