с помощью оператора SET. После выхода из процедуры значение, хранящееся в переменной ©ErrorLogID, передается в вызывающий сценарий.

Еще раз воспользуемся примером применения конструкции TRY/CATCH, приведенным в заключительной части предьщущей главы, но на этот раз выполним вызов процедуры uspLogError: USE AdventureWorks

BEGIN TRY

-- Предпринимается попытка создать таблицу CREATE TABLE OurlFTest(

Coll int PRIMARY KEY

END TRY BEGIN CATCH

-- Возникла какая-то ошибка; попытаемся определить, известен ли способ

-- ее исправления

DECLARE ©MyOutputParameter int

IF ERROR NUMBER() = 2714 -- Обнаруживается ошибка, указывающая на то, что

-- объект уже существует, но в этом нет ничего -- неожиданного

BEGIN

PRINT WARNING: Skipping CREATE as table already exists EXEC dbo.uspLogError ©ErrorLogID = ©MyOutputParameter OUTPUT PRINT A error was logged. The Log ID for our error was + CAST(©MyOutputParameter AS varchar)

ELSE --Ho эта ошибка не может быть распознана, поэтому о ней необходимо -- сообщить и больше ничего не предпринимать RAISERROR(something not good happened this time around, 16, 1 ) END CATCH

После вызова этой процедуры применительно к базе данных, в которой еще отсутствует таблица OurlFTest, будет получен следующий простой результат: Command(s) completed successfully.

Но если эта процедура будет вызвана на выполнение с указанием базы данных, в которой уже существует таблица OurlFTest (например, процедура будет выполнена дважды, притом что прежде еще не применялся соответствующий код оператора CREATE), то будет получена определенная информация, указывающая на наличие ошибки:

WARNING: Skipping CREATE as table already exists A error was logged. The Log ID for our error was 3

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

SELECT * FROM ErrorLog

WHERE ErrorLogID = 3 -- Это значение заменяется тем значением, которое, как

-- указывают полученные результаты, было внесено в журнал

Полученные результаты позволяют убедиться в том, что ошибка действительно была зарегистрирована должным образом: ErrorLogID UserName ErrorMessage

3 dbo There is already an object named OurlFTest -

(1 row(s) affected)

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

Ключевое слово OUTPUT для выходного параметра в объявлении хранимой процедуры является обязательным.

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

Переменная, которой присваивается результат вычисления значения выходного параметра, не обязательно должна иметь то же имя, что и внутренний параметр хранимой процедуры. Например, в приведенной выше хранимой процедуре внутренний параметр имел имя ©LogErrorlD, а переменная, которой присваивалось значение этого параметра, имела имя ©MyOutputVariable.

Без ключевого слова EXEC (или EXECUTE) нельзя было обойтись, поскольку оператор вызова хранимой процедуры не находился в пакете на первом месте. Безусловно, ключевое слово EXEC можно не указывать, если вызов хранимой процедуры приведен в пакете в первую очередь, но автор рекомендует усвоить привычку всегда применять это ключевое слово, независимо от прочих обстоятельств.

Подтверждение успешного или неудачного завершения работы с помощью возвращаемых значений

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

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

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

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

Способ использования оператора return

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

Чтобы передать некоторое возвращаемое значение из хранимой процедуры обратно в вызывающий код, достаточно применить оператор RETURN: RETURN [<integer value to return>]

Обратите внимание на то, что возвращаемое значение должно быть целочисленным.

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

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

USE AdventureWorks GO

CREATE PROC spTestReturns AS

DECLARE ©MyMessage varchar(50)