Question

我知道我们可以使用某些方法来确定我们自己的存储过程是否已成功执行。（使用输出参数，如果已经执行了没有任何错误，则在存储过程的末尾放置选择，例如选择1，...）

哪一个更好，为什么？

Answer 1

如果程序中出现错误，则使用RAISERROR可以与大多数客户端集成，而不是使用伪输出参数。他们只是调用过程并且RAISERROR在客户端应用程序中转换为异常，并且应用程序代码很难避免异常，它们必须被捕获并处理。

Answer 2

有一个清楚说明SP是否已创建的打印声明将更具可读性。

e.g。

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

Answer 3

SP非常像方法/子程序/程序＆amp;他们都有完成任务。任务可以像计算和计算一样简单。返回结果或者只是对表中记录的简单操作。根据任务的不同，您可以返回一个out值，表示任务的结果，无论是成功，失败还是实际结果。

Answer 4

如果您需要为整个项目/数据库使用通用的T-SQL解决方案，则可以对所有过程使用output参数。但RAISEERROR是处理客户端代码错误的方法，而不是T-SQL。

Answer 5

为什么不使用可以在代码中处理的不同返回值？

Answer 6

不需要引入额外的输出参数或额外的选择。

如果您唯一需要知道的是是否存在问题，那么成功执行就足够了。看看XACT_ABORT和TRY ...... CATCH here和here的讨论。

如果您想知道具体错误，return code是将此信息传递给来电者的正确方法。

Answer 7

在大多数生产方案中，我倾向于在数据库层中部署自定义错误报告组件，作为解决方案的一部分。没什么好看的，只有少数几个日志表和一些管理错误记录过程的存储过程。

然后使用SQL Server 2005及更高版本中提供的TRY-CATCH-BLOCK功能封装在生产服务器上执行的所有存储过程代码。

这意味着在特定存储过程失败的不太可能的情况下，发生的错误的详细信息和生成它的存储过程将记录到日志表中。从CATCH BLOCK中进行简单的存储过程调用，以记录相关细节。

此实施的基础实际上已在网上书籍here

中解释

如果您愿意，可以轻松扩展此实施，例如将电子邮件通知合并到DBA，甚至可以根据错误的严重程度发送SMS警报。

此类实现可确保如果您的存储过程未报告失败，那么它当然是成功的。

一旦拥有一个简单而强大的框架，就可以直接将基础实现复制并推广到其他生产服务器/应用程序平台。

这里没什么特别的，只是简单的错误记录和报告有效。

另一方面，如果您还需要再次记录存储过程的成功执行，可以设计一个包含日志表的类似解决方案。

我认为这个问题在博客上大肆宣传...... ..

确定我们自己的存储过程是否已成功执行的最佳方法是什么

7 个答案: