Хелен Борри - Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ
- Название:Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ
- Автор:
- Жанр:
- Издательство:БХВ-Петербург
- Год:2006
- Город:Санкт-Петербург
- ISBN:5-94157-609-9
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Хелен Борри - Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ краткое содержание
Рассмотрены вопросы, необходимые разработчику для создания клиент-серверных приложений с использованием СУБД Firebird, явившейся развитием СУБД Borland Interbase 6. Содержится обзор концепций и моделей архитектуры клиент/сервер, а также практические рекомендации по работе с клиентскими библиотеками Firebird. Детально описаны особенности типов данных SQL, язык манипулирования данными (Data Manipulation Language, DML), а также синтаксис и операторы языка определения данных ( Data Definition Language, DDL). Большое внимание уделено описанию транзакций и приведены советы по их использованию при разработке приложений. Описано программирование на стороне клиента и сервера написание триггеров и хранимых процедур, создание и использование событий базы данных, обработка ошибок в коде на сервере и многое другое. Материал сопровождается многочисленными примерами, советами и практическими рекомендациями.
Для разработчиков баз данных
Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
Пользовательские исключения, доступные только в модулях PSQL, не должны дублировать работу внутренне определенных исключений. Определяйте ваши исключения для использования там, где вы хотите в вашем коде выявлять ошибочные ситуации, которые нарушают ваши бизнес-правила. Три вида исключений изображены на рис. 32.1.
У нас был в главе 30 пример, в котором пользовательское исключение применялось в триггере для прекращения события, продолжение которого нарушило бы бизнес-правило. В этом случае хранимая процедура позаботится о том, чтобы убрать зависимости из организационной структуры при удалении служащего. Это было объявлено следующим образом:
CREATE EXCEPTION REASSIGN_SALES
'Reassign the sales records before deleting this employee.' ^
/* Переназначьте записи продаж перед удалением этого служащего */
COMMIT ^

Рис. 32.1. Стандартная реакция PSQL на исключения
В том месте, где используется это исключение, процедура проверяет, является ли данный служащий участником продаж в каком-либо документе продаж. Если да, то используется пользовательское исключение для завершения процедуры. Конечно, если возникает исключение, то все другие действия, выполненные в процедуре, отменяются.
BEGIN
IE (EXISTS (SELECT PO_NUMBER FROM SALES
WHERE SALES_REP = : emporium) ) THEN
EXCEPTION reassign_sales;
! ! !
ПРИМЕЧАНИЕ. В хранимых процедурах выбора выходные строки, которые уже были получены клиентом в предыдущих циклах FOR SELECT ... DO ... SUSPEND, остаются доступными для клиента. О механизме, работающем в этом случае, см. далее разд. "Оператор WHERE".
. ! .
Существуют случаи, когда возможно использовать пользовательское исключение как способ вмешательства в возникшую проблему и позволить процедуре продолжать выполнение. Вы можете перехватить исключение и написать код для его обработки прямо в этой процедуре. В следующем разделе рассматривается, каким образом эта техника перехвата и исправления может быть использована при исключении REASSIGN_SALES.
Обработка исключений
Код PSQL может перехватывать ошибки при их появлении и затем их обрабатывать в подпрограмме обработки исключений. Если исключение будет обработано в вашем коде- вы обеспечите исправление или обход ошибки и позволите продолжить выполнение, - то клиенту не возвращается никакого сообщения об исключении. Рис. 32.2 иллюстрирует логику перехвата и обработки ошибок.
Как и раньше, исключение приводит к прекращению выполнения в блоке. Вместо того чтобы передать выполнение на конечный оператор END, теперь процедура отыскивает уровни во вложенных блоках, начиная с блока, где была выявлена ошибка, и переходит на внешние блоки, чтобы найти код обработчика, который "знает" о таком исключении. Она отыскивает первый оператор WHEN, который может обработать эту ошибку.
Оператор WHEN
Оператор WHEN имеет следующую форму:
WHEN <���исключение> DO <���составной-оператор>
Здесь исключение может быть одним из следующих:
<���имя-исключения> | GDSCODE код | SQLCODE код \ ANY
<���составной-оператор> может быть одним оператором или множеством обычных операторов PSQL, заключенным в блок BEGIN ... END.

Рис. 32.2. Логика перехвата и обработки ошибок
Принцип типов исключений, показанный в структурах синтаксиса, представляет объем области видимости.
Пользовательское исключение может соответствовать любому выбранному вами условию, включая правила, которые вы, может быть, не в состоянии реализовать с помощью выражений в ограничениях. Операторы WHEN и код обработчика пользовательских исключений лучше всего поместить в тот же блок, где может появиться ошибка.
Следующим по глубине является GDSCODE. В версии 1.0.x это контекстная переменная, в которой процедура может только получить код и сравнить его с кодом, заданным в предикате WHEN:
WHEN GDSCODE foreign_key DO
BEGIN
. . .
END
Начиная с версии 1.5, GDSCODE является "полнофункциональной" контекстной переменной. При ее чтении внутри блока, где возникло исключение, вы можете сохранить этот код в записи протокола.
! ! !
СОВЕТ. Все коды GDSCODE имеют символические константы, которые являются более или менее понятными для людей, знающих английский язык. Именно эти символические константы вы должны использовать в операторах WHEN GDSCODE, а не числовые коды. Если вы посмотрите заголовочный файл iberror.h в вашем каталоге /include, вы увидите, что определение символических констант имеют префикс isc_. Этот префикс должен быть опущен в операторах WHEN GDSCODE.
. ! .
Некоторые ошибки, выявленные в GDSCODE, могут быть исправлены внутри области действия блока, где они появились. Если это так, то оператор WHEN для обработки таких ошибок должен находиться здесь, иначе он должен быть помещен во внешний цикл для обработки там ошибок.
Код SQLCODE является довольно общим, он не всегда соответствует типу ошибки. Операции SQL передают SQLCODE 0 при успешном завершении и SQLCODE 100 при достижении конца файла. Диапазон неиспользуемых "сегментов" находится между 1 и 99 для предупреждающих и информационных сообщений. Диапазон ошибок SQLERROR - отрицательные числа, которые больше -1000. Такие коды ошибок SQLERROR в SQLCODE обычно являются группировкой на более высоком уровне нескольких кодов GDSCODE.
Как и GDSCODE, SQLCODE допускает только программное чтение в версии 1.0.x, но становится настоящей контекстной переменной в версии 1.5 и более поздних. Вы можете поместить это значение в протокол.
! ! !
ПРИМЕЧАНИЕ. Вы можете использовать либо GDSCODE, либо SQLCODE. Вы получите код для одного и NULL для другого.
. ! .
Коды SQLCODE менее детализированы и в большинстве случаев менее всего подходят для условий, которые могут быть исправлены внутри модуля. Посмотрите коды в приложении 10, обратите внимание, что один код SQLCODE чаще всего группирует несколько кодов GDSCODE. Обычно они более полезны во внешнем блоке модуля.
Ключевое слово ANY- это "оставшиеся исключения". Оно означает перехват любого определенного внутренне исключения, которое не было обработано. В версии 1.5, наряду с возможностью чтения GDSCODE или SQLCODE (в рамках области действия), у ANY
есть лучшая возможность создания обработчика по умолчанию, чем в предыдущих версиях.
Всегда помещайте ваши блоки WHEN непосредственно перед оператором END, закрывающим тот блок, исключения которого вы хотите обрабатывать. Не помещайте никакие другие операторы - даже SUSPEND или EXIT - между концом ваших обработчиков и завершающим оператором END. Вернитесь к рис. 32.2, где описан этот поток.
Читать дальшеИнтервал:
Закладка: