Хелен Борри - Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

Как и в случае с хранимыми процедурами, подтверждение изменений вызовет печально известную ошибку "объект находится в использовании" (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: обработка пользовательских исключений и события. С помощью исключений вы имеете весьма детальный контроль над перехватом и обработкой сотен внутренне определенных условий ошибок и множеством ваших собственных исключений. С помощью событий вы можете реализовать механизм обратных вызовов, чтобы проинформировать приложения удаленных клиентов о подтвержденных изменениях, выполненных другими клиентами.

В этой главе мы рассмотрим, как при выполнении модулей PSQL - триггеров и процедур - можно перехватывать и обрабатывать ошибки в выполняемом коде.

Стандартным поведением модулей PSQL при появлении исключений является остановка выполнения, отмена всей работы, выполненной с начального оператора BEGIN, переход на конечный оператор END и возврат управления клиенту с передачей одного или более сообщений об ошибке. Если этим модулем является триггер, исключение отменит работу всех предыдущих триггеров и предотвратит посылку запрашиваемых изменений DML.

Может появиться три типа исключений.

* Ошибки SQL - т. е. сообщения SQL, имеющие отрицательное значение SQLCODE.

* Внутренние ошибки Firebird, которые имеют отношение к конкурирующему взаимодействию, данным, метаданным и условиям окружения. У них есть девяти- символьный код ошибки, обычно начинающийся с 3355, который уникально идентифицирует код GDSCODE. Большинство кодов GDSCODE попадают в обобщающие группы кодов SQLCODE, и при возникновении исключения вы обычно получаете и SQLCODE, и GDSCODE.

* Пользовательские исключения, которые вы объявляете как постоянные объекты базы данных и "вызываете" в коде, когда определяется специфическое условие.

Исключение - это просто сообщение, которое генерируется, когда появляется ошибка.

Все предварительно определенные исключения - SQLCODE и GDSCODE - имеют ассоциированные с ними тексты сообщений. Сообщения по умолчанию на английском языке, но могут использоваться и другие языки. Существует небольшое количество версий сообщений на других языках (включая латинский!), другие или "находятся в работе", или "ожидают желающих поработать" [127] Как показывает практика, такие переводы не приносят ожидаемой пользы разработчикам. Сообщения сервера ориентированы на разработчика приложений, и даже будучи переведенными, слишком сложны для восприятия пользователем программы. Более грамотным является корректная обработка ошибок, возникающих на сервере, в коде клиентского приложения, и выдача пользователю осмысленных и понятных сообщений в контексте прикладной области. Не составляет сложености в это же время сохранять исходные сообщения от сервера в специальном файле для последующего анализа корректности работы приложения - Прим. науч. ред. .

В Firebird существует синтаксис DDL для создания пользовательских исключений с текстами сообщений до 78 символов. В Firebird 1.5 вы можете расширить ваши пользовательские исключения во время выполнения, заменить текст сообщения, посылаемого по сети, в зависимости от контекста.

Создание исключения является одним из самых простых элементов DDL. Синтаксис:

CREATE EXCEPTION имя-исключения <���сообщение>;

Имя-исключения- обычный идентификатор Firebird до 31 символа длиной. Оно должно быть уникальным среди идентификаторов исключений, а в диалекте 3 может быть заключено в кавычки. Тогда имя будет чувствительным к регистру.

<���сообщение> - заключенная в апострофы строка текста в наборе символов NONE. Из-за ограничения размера текст должен быть лаконичным. Например:

CREATE EXCEPTION NO_DOGS 'NO dogs allowed!'; COMMIT;

Оператор CREATE EXCEPTION должен быть подтвержден, как и любой другой оператор DDL.

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

Для удаления нашего исключения NO_DOGS введите:

DROP EXCEPTION NO_DOGS;

Для его изменения:

ALTER EXCEPTION NO_DOGS 'NO dogs allowed except Irish Wolfhounds!';

! ! !

СОВЕТ. При конструировании скриптов схемы сгруппируйте вместе все ваши операторы CREATE EXCEPTION, чтобы их было проще отыскивать в процессе разработки и модификации, а также с целью документирования. Разработчики часто используют короткие префиксы или какую-нибудь систему именования исключений в соответствии с категориями пользовательских исключений.

. ! .

Внутренне определенные исключения вызываются ядром сервера в ответ на соответствующие ошибки, которые требуют прекращения выполнения. Они охватывают большое количество условий, включая каждый вид нарушения ограничений, арифметические и строковые переполнения, ссылки на отсутствующие объекты, разрушение данных и т.д. Исключения SQLCODE и GDSCODE являются теми же самыми исключениями, что и исключения, используемые при появлении ошибок в процессе выполнения операций динамического SQL. Они описаны в приложении 10.