Шрифт:
* операторы CONNECT/DISCONNECT и отправки операторов SQL другим базам данных;
* GRANT/REVOKE;
* EVENT INIT/EVENT WAIT;
* BEGIN DECLARE SECTION/END DECLARE SECTION;
* BASED ON;
* WHENEVER;
* DECLARE CURSOR;
* OPEN;
* FETCH;
* любые операторы, начинающиеся с ключевых слов SET и SHOW.
Исключения
Обработчики исключений могут быть написаны, чтобы "съесть" ошибку, обрабатывая ее разными способами. Например, в итеративной подпрограмме входная строка, вызывающая исключение, необязательно должна приводить к остановке всего процесса. Обработка исключения внутри триггера или хранимой процедуры может позволить пропустить проблемную входную строку - например, поместив сообщение об ошибке в протокол в текстовый файл или в таблицу ошибок - и дав возможность продолжить дальнейшую обработку.
Код в модуле может обрабатывать ошибку в необязательном фрагменте кода, называемом блоком исключения, который является последовательностью операторов, заключенных в операторные скобки BEGIN и END, которым предшествует ключевое слово WHEN.
Необработанное исключение останавливает процесс, отменяет всю выполненную к этому моменту работу [112] и возвращает сообщение об ошибке приложению. Вы также можете написать код, вызывающий пользовательское исключение и останавливающий процесс. Вы можете обработать эту ошибку в вашем коде или остановить процесс и вернуть пользовательское сообщение клиентскому приложению. Если модуль является триггером, то операция DML, в которой появилась эта ошибка, также будет отменена. В базе данных вы можете создать столько пользовательских исключений, сколько вам нужно. Начиная с версии 1.5, вы можете использовать данные времени выполнения и конструировать тексты для ваших сообщений об исключениях "на лету".
112
Только в отношении работы конкретного запроса SQL, выполненного из клиентского приложения, в "недрах" которого произошла ошибка. Работа, выполненная ранее другими запросами SQL в этой же транзакции, будет сохранена (если транзакция завершится по commit).
– Прим. науч. ред.
Обработка исключений и ошибок подробно обсуждается в главе 32.
События
События Firebird являются "сигналами", которые модули PSQL могут накапливать в процессе выполнения для передачи клиентским приложениям, когда работа будет подтверждена. Клиентские приложения в сети могут прослушивать- с использованием обработчика сообщений- конкретные события, в которых они заинтересованы, без необходимости специального опроса наличия события.
Программирование с событиями и задание приложениям указания на их прослушивание рассматривается в главе 32.
Безопасность
Процедурам и триггерам могут быть предоставлены привилегии для специфических действий (SELECT, INSERT, DELETE и т.д.) к таблицам точно так же, как пользователям или ролям предоставляются привилегии. Не существует специального синтаксиса: используется обычный оператор GRANT, но в предложении то указывается триггер или процедура вместо пользователя или роли. Аналогичным образом привилегии процедур и триггеров могут отменяться оператором REVOKE.
Не всегда существует необходимость предоставлять привилегии модулям процедур или триггеров. Достаточно либо пользователю, либо модулю иметь привилегии к действиям, выполняемым модулем.
Например, если пользователь выполняет UPDATE для таблицы А, что вызывает триггер, а триггер выполняет INSERT для таблицы в, то это действие будет допустимым, если пользователь имеет привилегии INSERT к этой таблице или триггер имеет привилегии INSERT к этой таблице.
Если у триггера или процедуры нет достаточных привилегий для выполнения их действий, Firebird вызывает ошибку SQL и устанавливает соответствующий код ошибки. Вы можете перехватить этот код ошибки в обработчике исключений точно так же, как и другие исключения. Информацию об операторах GRANT и REVOKE см. в главе 35.
Внутреннее устройство технологии
Когда любой запрос вызывает хранимую процедуру, то текущее определение этой хранимой процедуры копируется в этот момент в кэш метаданных. В Классическом сервере эта копия присутствует в течение всего времени пользовательского соединения. В Суперсервере она сохраняется "живой", пока не будет отключено последнее соединение.
Запрос приходит от одного из следующих объектов:
* от клиентского приложения, которое напрямую выполняет хранимую процедуру;
* от триггера, который выполняет хранимую процедуру. Сюда относятся и системные триггеры, являющиеся частью систем поддержания ссылочной целостности или ограничений CHECK;
* от другой хранимой процедуры, которая выполняет эту хранимую процедуру.
Эффекты изменений
Однажды вызванный запрос к триггеру или хранимой процедуре сохраняется в кэше метаданных, пока существуют клиентские соединения с базой данных, независимо от того, использует ли какой-нибудь клиент этот триггер или хранимую процедуру. Не существует механизма убрать эти невыполняющиеся запросы из кэша метаданных. По этой причине изменения модулей PSQL являются "отложенными" в большей или меньшей степени в большинстве случаев. Возможность для клиентов видеть эти изменения отличается для Классического сервера и Суперсервера.
Поскольку существующие запросы удаляются из кэша метаданных только тогда, когда последний клиент отключится от базы данных, они вообще никогда не будут обновлены в системах 24/7 (т. е. в системах, работающих 24 часа в сутки и 7 дней в неделю). Существует только один способ гарантировать, что все копии хранимых процедур и триггеров будут удалены из кэша метаданных - завершение всех соединений с базой данных. Когда пользователи снова соединятся с базой данных, они все увидят новые версии хранимых процедур и триггеров.