Question

我正在尝试清理一个巨大的遗留T-SQL存储过程。我们从BizTalk中调用它。 BizTalk具有在出错时重试发送端口（例如每5分钟3次）的功能。

例如，存储过程会检测到丢失的数据并执行此操作：

   if @CompanyID is null        raiserror( '@CompanyID is missing', 18, 1 );

“Begin Catch”逻辑处理某些错误（即将它们记录到错误表中），然后执行“返回0”。我相信之前的程序员认为这会让BizTalk再次调用它。但现在我有一个跟踪，我可以证明BizTalk每隔y分钟调用它x重试（由BizTalk SendPort定义）。

我目前的想法是，如果@@ Error和@@ ErrorMessage不为空，BizTalk仍然认为它是错误的，并将重试。

有关如何彻底清除错误的任何想法？我希望能做一个小的快速修复，没有时间进行重大改写。

Answer 1

这可能不适用但如果您提高错误级别，则可能会导致更严重的错误记录，从而解决问题。通常1到19我相信更多信息相关，20后被认为是致命错误，并将在SQL日志中记录错误。这可能会迫使程序停止，即使处理程序仍然认为它是打开的。您可以随时测试它，看看它是否符合您的需求，如果没有，则将其更改。您也可以尝试更合适的BEGIN END阻塞，并且通用返回不返回捕获的值，如：

IF @CompanyID is NULL
  BEGIN
     Raiserror('@CompanyID is missing', 20, 1);
     return;
  END

有关错误捕获的详情：http://msdn.microsoft.com/en-us/library/ms178592.aspx

Answer 2

如果错误处理是基于SQL的，那么听起来你可能想要完全替换你的RAISERROR，而是在那时记录你的错误并简单地返回。

此外，@@ Error永远不会为空。它将为每个执行的语句返回一个“new”值。如果前一个语句成功执行，它将返回0，否则它将返回错误号....在你的情况下将是18.如果你的逻辑键是@@ Error，那么你需要确保它正在检查（或保存到变量中）正在执行相关语句之后。

以下更多信息。

http://technet.microsoft.com/en-us/library/ms190193(v=sql.100).aspx

Answer 3

我认为这篇文章基本上回答了我的问题（这也是我的一篇文章，放大了与catch块内错误处理相关的说明）：

T-SQL is error handling totally turned off in a "BEGIN CATCH" block?

try catch中的某些语句不会爆炸。他们可以设置错误，代码不断下降。

在这种特定情况下，catch块有一个Insert到表中，并且已在存储过程中展开了一列，但未在错误表中展开。我们可能在4个月之前扩展了其他表中的列，但是直到本周我们才从错误处理程序中找到这个隐蔽的隐藏问题。

我认为其他StackOverflow帖子最终会帮助解答为什么BizTalk将此视为错误的问题。我认为“返回0”会这样做。但是由于我们遇到了截断问题，因此该错误被发送到BizTalk。

在现实世界中，我们很少遇到此错误代码，而当我们这样做时，导致错误的特定列不是太大。当QA人员开始某个测试场景并且输入一些无效的航班号以及违规列的特别长的值时，就会出现此错误。

T-SQL清除错误

3 个答案: