Опция WITH LOG

Опция WITH LOG сообщает СУБД SQL Server, что сообщение об ошибке должно быть внесено в журнал ошибок SQL Server и в журнал пршожения Windows. Применение этой опции является обязательным в сочетании с сообщениями, имеющими степень серьезности 19 или выше.

Опция WITH SETERROR

По умолчанию при выполнении оператора RAISERROR системной переменной @@ERROR не присваивается идентификатор сформированного сообщения об ошибке. Вместо этого значение системной переменной @@ERROR фактически отражает результат успешного или неудачного выполнения оператора RAISERROR. Опция WITH SETERROR позволяет отменить такое действие, чтобы системной переменной @@ERROR присваивалось значение, равное идентификатору сообщения об ошибке.

Опция WITH NOWAIT

При использовании опции WITH NOWAIT клиентское прр1ложение немедленно получает уведомление о возникновении ошибки.

Ввод в систему определяемых пользователем сообщений об ошибках

Для ввода в систему дополнительных сообщений об ошибках может применяться специальная системная хранимая процедура, sp addmessage, которая имеет следующий синтаксис:

sp addmessage [©msgnum =] <message id>,

[©severity =] <severity>,

[©msgtext =] <msg>

[, [©lang =] <language >]

[, [©with log =] [TRUE I FALSE]]

[, [©replace =] replace]

Bee параметры этой процедуры имеют практически то же назначение, что и параметры оператора RAISERROR, за исключением того, что в последнем случае дополнительно введен параметр с обозначением языка и параметр REPLACE, а также внесены небольшие изменения в опцию WITH LOG.

Параметр @lang

Параметр @lang позволяет указать, к какому языку программирования относится данное сообщение. Возможность предусмотреть отдельную версию сообщения для любого языка, о поддержке которого указано в таблице sys languages, является очень ценной. Применение этой опции равносшьно применению псевдонима, если список языков выбирается из таблицы sys . sys languages.

Параметр ©withlog

Параметр @witli log во многом аналогичен опции WITH LOG, предусмотренной в операторе RAISERROR, поскольку если этому параметру присвоено значение TRUE, то сообщения после их активизации автоматически регистрируются и в журнале ошибок SQL Server, и в журнале пршожения Windows. Единственный нюанс, который приходится при этом учитывать, состоит в том, что для указания необходимости

регистрации сообщений данному параметру присваивается значение TRUE, а не используется опция WITH LOG.

Следует очень критически относиться к сказанному об этюм в документации Books Online. При недостатхмно внимательном прочтении описания данной темы в документации можно вполне интерпретировать сказанное так, будтю параметру @with log следует присвоить значение строковой константы WITH LOG, тогда как фактически должно быть присвоено значение TRUE. По-видимому, еще большую путаницу вносит тю, что параметр ©replace на первый взгляд кажется почти аналогичным по способу его иепользования, но ему должно быть присвоено значение строковой константы, а не TRUE.

Параметр ©replace

Если с помощью процедуры sp addmessage редактируется существующее сообщение, а не создается новое, то параметру ©replace необходимо присвоить значение REPLACE. А при попытке отредактировать текст существующего сообщения без применения этого параметра активизируется сообщение об ошибке.

Рекомендуем создать заранее заданный список дополнительных сообщений, предназначенный для применения во всех разрабатываемых приложениях, поскольку это позволяет намного увеличить степень многократного использования сообщений, а также, что еще более важно, существенно повысить удобство чтения кода приложения. Достаточно представить себе, насколько это удобно, если в каждом из приложений для базы данных используется постоянный список определяемых пользователем кодов ошибок. В таком случае можно легко подготовить файл с константами (например, ресурс или включаемую библиотеку), который содержит список применяемых сообщений об ошибках. При таком подходе можно даже подготовить включаемую библиотеку, в которой предусмотрены универсальные средства обработки некоторых или даже всех ошибок. Короче говоря, если вы намереваетесь разработать большое количество приложений для СУБД SQL Server в одной и той же среде, то рассмотрите возможность создать список сообщений об ошибках, общий для всех разрабатываемых приложений.

Использование хранимой процедуры spaddmessage

Как уже было сказано, с помощью хранимой процедуры sp addmessage в базу данных можно ввести сообщения, активизируемые с помощью оператора RAISERROR, в основном таким же образом, как активизируются произвольные сообщения.

Рассмотрим пример добавления в базу данных собственного определяемого пользователем сообщения, с помощью которого формируется предупреждение о том, что приведенная дата заказа является недопустимой:

sp addmessage

©msgnum = 60000, ©severity = 10,

©msgtext = %s is not a valid Order date. Order date must be within 7 days of current date.

После вызова на выполнение этой хранимой процедуры появляется подтверждение того, что в базу данных добавлено новое сообщение: (1 row(s) affected)

Прр1 вызове на выполнение хранимой процедуры sp addmessage сообщение фактически добавляется в таблицу sysmes sages базы данных master, независимо от того, с какой базой данных вы в этот момент работаете. Такая особенность рассматриваемой хранимой процедуры является очень важной, поскольку i после переноса базы данных на новый сервер необходимо снова вводить пользова-г тельские сообщения в базу данных master этого нового сервера. Пользовательские сообщения не переносятся из базы данных master применявшегося ранее сервера в базу данных master нового сервера автоматически. Поэтому автор настоятельно рекомендует храш1ть все определяемые пользователем сообщения в отдельном сценарии, чтобы их всегда можно было легко ввести в новую систему.

Удаление существующего сообщения, определяемого пользователем

Чтобы удалить из базы данных одно из определяемых пользователем сообщений, достаточно выполнить следующее: sp dropmessage <msg num>

Практическое применение хранимых процедур

Выше в данной главе рассматривались многие темы, касающиеся способов создания хранимой процедуры, а данный раздел в основном посвящен описанию областей применения хранимых процедур. Некоторые из этих областей применения главным образом не требуют пояснений, тогда как другие могут оказаться не столь очевидными для тех, кто только осваивается в мире реляционных СУБД. Основные преимущества хранимых процедур перечислены ниже.

Реализация возможности запуска процессов, которые требуют выполнения процедурньгх действий.

Обеспечение защиты.

Повышение производительности.

Создание вызываемых процессов

Как уже было сказано, хранимая процедура - это своего рода сценарий, хранящийся в базе данных. Иначе говоря, хранимая процедура представляет собой объект базы данных, и в этом есть свое преимущество, поскольку она может быть непосредственно вызвана на выполнение. Иначе говоря, для вызова такого программного объекта, как хранимая процедура, на выполнение не требуется вручную загружать его из файла.

Хранимые процедуры могут применяться для вызова других хранимых процедур (по так называемому принципу вложения). В версии SQL Server 2005 допускается вложение хранимых процедур на глубину до 32 уровней. Это дает возможность многократно использовать отдельные хранимые процедуры в основном по такому же принципу, как используются подпрограммы в классических процедурных языках программирования. Синтаксис вызова одной хранимой процедуры из другой является точно таким же, как и синтаксис вызова хранимой процедуры из сценария.