Как лучше всего определить, была ли наша собственная хранимая процедура выполнена успешно или нет

Question

Я знаю несколько способов, которые мы можем использовать, чтобы определить, была ли наша собственная хранимая процедура выполнена успешно или нет. (используя выходной параметр, помещая select, например select 1, в конец хранимой процедуры, если она была выполнена без ошибок, ...)

так какой из них лучше и почему?

Answer 1

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

Answer 2

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

Весь код хранимой процедуры, выполняемый на рабочем сервере, затем инкапсулируется с помощью функции TRY-CATCH-BLOCK, доступной в SQL Server 2005 и более поздних версиях.

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

Основы для этой реализации на самом деле объясняются в книгах онлайн здесь

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

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

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

Ничего особенного, только простая регистрация ошибок и создание отчетов.

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

Я думаю, что этот вопрос кричит для сообщения в блоге …… ..

Answer 3

Ввод дополнительного выходного параметра или дополнительного выбора не требуется.

Если вам нужно только знать, есть ли проблема, успешное выполнение - это достаточно хороший выбор. Посмотрите на обсуждения XACT_ABORT и TRY ... CATCH здесь и здесь .

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

Answer 4

Почему бы не использовать различные возвращаемые значения, которые затем могут быть обработаны в коде?

Answer 5

Если вам нужно общее решение T-SQL для всего вашего проекта / базы данных, вы можете использовать выходной параметр для всех процедур. Но RAISEERROR - это способ обработки ошибок в коде вашего клиента, а не T-SQL.

Answer 6

SP очень похож на метод / подпрограмму / процедуру, и у всех них есть задача, которую нужно выполнить. Задача может быть такой же простой, как вычисление и возврат результата, или может быть простой манипуляцией с записью в таблице. В зависимости от задачи вы можете либо вернуть значение out, указывающее результат задачи, будь то успех, сбой или фактические результаты.

Answer 7

Наличие оператора печати, в котором четко указано, был ли создан SP или нет, будет более читабельным.

, например

CREATE PROCEDURE CustOrdersDetail @OrderID int
AS
...
...
...
GO
IF OBJECT_ID('dbo.CustOrdersDetail') IS NOT NULL
    PRINT '<<< CREATED PROCEDURE dbo.CustOrdersDetail >>>'
ELSE
    PRINT '<<< FAILED CREATING PROCEDURE dbo.CustOrdersDetail >>>'
GO