DECLARE ©MyOtherMessage varchar(50)

SELECT ©MyMessage = Hi, its that line before the RETURN

PRINT ©MyMessage

RETURN

SELECT ©MyOtherMessage = Sorry, but we wont get this far PRINT ©MyOtherMessage RETURN

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

Какой вывод осуществляется из хранимой процедуры.

Какое значение возвращает оператор RETURN.

Для перехвата значения, возвращаемого оператором RETURN, необходимо предусмотреть в операторе EXEC присваивание этого значения переменной. Например, в следующем коде возвращаемое значение присваивается переменной ©ReturnVal: EXEC ©ReturnVal = spMySproc

Теперь поместим этот оператор в более удобный сценарий для проверки хранимой процедуры:

DECLARE ©Return int

EXEC ©Return = spTestReturns SELECT ©Return

Этот сценарий является небольшим, но весьма интересным. После вызова его на выполнение можно убедиться в том, что оператор RETURN действительно прекращает выполнение кода так, что больше не может быть выполнен ни один оператор: Hi, its that line before the RETURN

(1 row{s) affected)

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

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

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

USE AdventureWorks GO

ALTER PROC spTestReturns AS

DECLARE ©MyMessage varchar(50)

DECLARE ©MyOtherMessage varchar(50)

SELECT ©MyMessage = Hi, ifs that line before the RETURN PRINT ©MyMessage RETURN 100

SELECT ©MyOtherMessage = Sorry, but we wont get this far PRINT ©MyOtherMessage RETURN

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

Hi, its that line before the RETURN

(1 row(s) affected)

Обработка ошибок

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

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

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

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

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

к СУБД SQL Server, продолжается, поэтому остается возможность перехватывать эти ошибки и отвечать на них должным образом.

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

Очевидно, что тематика, касающаяся обработки ошибок, является очень сложной. Кроме того, с выпуском каждой версии SQL Server происходят важные изменения в подходах к обработке ошибок, о чем мы постараемся рассказать в данном разделе.

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

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

Применявшиеся ранее методы обработки ошибок

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

Обработка побочных ошибок

Побочные ошибки представляют собой те небольшие, но неприятные нарушения в работе, из-за которых функционирование СУБД SQL Server продолжается, как прежде, но по каким-то причинам намеченные действия оканчиваются неудачей. Например, попытаемся вставить в таблицу Sales . StoreContact такую строку, которая не имеет соответствующей ей строки в таблице Customers или Contacts: