Шрифт:
ALTER TRIGGER SET_CUST_NO
BEFORE INSERT AS
BEGIN
IF (NEW.CUST_NO IS NULL) THEN
NEW.CUST_NO = GEN_ID(CUST_NO_GEN, 1);
INSERT INTO NEW_CUSTOMERS(NEW.CUST_NO, CURRENT_DATE) END ^
SET TERM ;^
В версии 1.5 этот новый синтаксис создает триггер, если триггер с указанным именем не найден, или изменяет триггер с этим именем. Просто отредактируйте исходный оператор CREATE нужным образом, добавив ключевые слова OR ALTER.
Как и в случае с хранимыми процедурами, подтверждение изменений вызовет печально известную ошибку "объект находится в использовании" (Object in use), если в настоящий момент какой-нибудь пользователь использует триггер или какой-либо объект, зависящий от него. В любом случае новая версия триггера не станет немедленно доступной в Суперсервере, если старая версия все еще находится в кэше. Все пользователи должны отключиться от базы данных, а когда они вновь подключатся, то смогут видеть новую версию.
В Классическом сервере новая версия будет доступна следующему клиенту, который соединится с базой данных.
В версии 1.5 и более поздних выполнение ALTER TRIGGER ... INACTIVE | ACTIVE обычно не приводит к ошибке "объект находится в использовании", если только существующая транзакция не заблокировала таблицу. Такое изменение не влияет на транзакции, которые уже используют эту таблицу. Причем данное изменение будет видимым следующей транзакции, которая запрашивает изменение состояния таблицы.
Удаление триггеров
В процессе проектирования базы данных и разработки приложений триггер может перестать быть полезным. Для удаления триггера соединитесь с базой данных как его владелец или пользователь SYSDBA и используйте оператор DROP TRIGGER.
Его синтаксис:
DROP TRIGGER ИМЯ;
Имя триггера должно быть именем существующего триггера. Следующий пример удаляет триггер SET_CUST_NO:
DROP TRIGGER SET CUST NO;
! ! !
ПРИМЕЧАНИЕ. Чтобы временно сделать триггер недоступным, используйте ALTER TRIGGER имя INACTIVE.
. ! .
Последняя глава этой части добавляет сахарную глазурь в наш торт для разработчиков базы данных. Firebird имеет две особенности PSQL: обработка пользовательских исключений и события. С помощью исключений вы имеете весьма детальный контроль над перехватом и обработкой сотен внутренне определенных условий ошибок и множеством ваших собственных исключений. С помощью событий вы можете реализовать механизм обратных вызовов, чтобы проинформировать приложения удаленных клиентов о подтвержденных изменениях, выполненных другими клиентами.
ГЛАВА 32. Обработка ошибок и события.
В этой главе мы рассмотрим, как при выполнении модулей PSQL - триггеров и процедур - можно перехватывать и обрабатывать ошибки в выполняемом коде.
Стандартным поведением модулей PSQL при появлении исключений является остановка выполнения, отмена всей работы, выполненной с начального оператора BEGIN, переход на конечный оператор END и возврат управления клиенту с передачей одного или более сообщений об ошибке. Если этим модулем является триггер, исключение отменит работу всех предыдущих триггеров и предотвратит посылку запрашиваемых изменений DML.
Типы исключений
Может появиться три типа исключений.
* Ошибки SQL - т. е. сообщения SQL, имеющие отрицательное значение SQLCODE.
* Внутренние ошибки Firebird, которые имеют отношение к конкурирующему взаимодействию, данным, метаданным и условиям окружения. У них есть девяти- символьный код ошибки, обычно начинающийся с 3355, который уникально идентифицирует код GDSCODE. Большинство кодов GDSCODE попадают в обобщающие группы кодов SQLCODE, и при возникновении исключения вы обычно получаете и SQLCODE, и GDSCODE.
* Пользовательские исключения, которые вы объявляете как постоянные объекты базы данных и "вызываете" в коде, когда определяется специфическое условие.
Что такое исключение?
Исключение - это просто сообщение, которое генерируется, когда появляется ошибка.
Все предварительно определенные исключения - SQLCODE и GDSCODE - имеют ассоциированные с ними тексты сообщений. Сообщения по умолчанию на английском языке, но могут использоваться и другие языки. Существует небольшое количество версий сообщений на других языках (включая латинский!), другие или "находятся в работе", или "ожидают желающих поработать" [127] .
127
Как показывает практика, такие переводы не приносят ожидаемой пользы разработчикам. Сообщения сервера ориентированы на разработчика приложений, и даже будучи переведенными, слишком сложны для восприятия пользователем программы. Более грамотным является корректная обработка ошибок, возникающих на сервере, в коде клиентского приложения, и выдача пользователю осмысленных и понятных сообщений в контексте прикладной области. Не составляет сложености в это же время сохранять исходные сообщения от сервера в специальном файле для последующего анализа корректности работы приложения - Прим. науч. ред.