您最喜欢调试 MS SQL 存储过程的方法是什么？答案

【问题标题】：What's your favored method for debugging MS SQL stored procedures?您最喜欢调试 MS SQL 存储过程的方法是什么？
【发布时间】：2009-03-05 17:25:38
【问题描述】：

我的大多数 SP 都可以使用手动输入的数据简单地执行（和测试）。这很好用，使用简单的 PRINT 语句可以让我“调试”。

但是，在某些情况下，会涉及多个存储过程，并且查找要输入的有效数据非常繁琐。从我的网络应用程序中触发事情会更容易。

我对分析器有一点经验，但我还没有找到一种方法来逐行探索我的存储过程中发生的事情。

你的方法是什么？

谢谢你，一如既往。

注意：我假设使用 SQL Server 2005+

【问题讨论】：

【解决方案1】：

Profiler 非常方便，只需添加 SP:StmtStarting 事件，并通过设置 SPID=xxx 将活动过滤到您的进程。设置好之后，就可以轻而易举地看到发生了什么。

【讨论】：

【解决方案2】：

您实际上可以将调试器附加到您的 sql server :) - 来自 vs，假设您已经在 sql server 上配置了它。

更新：关于“然而，在某些情况下，涉及多个存储过程并且查找要输入的有效数据是乏味的。从我的网络应用程序中触发事情更容易。 "

我建议您设置集成测试，重点关注与这些过程交互的特定方法。如果程序是由 Web 应用程序驱动的，那么这是一个可以随时运行有效测试 + 输入的好地方。如果有多个应用程序与程序交互，我会考虑对程序进行单元测试。

【讨论】：

【解决方案3】：

我更喜欢只使用存储过程来检索数据集，并在应用程序端做任何复杂的“工作”。因为您是正确的，所以尝试“调试”在许多分层、游标循环、使用临时表、嵌套存储过程的内部发生的事情是非常困难的。

也就是说，MS KB 316549 描述了如何使用 Visual Studio 来调试存储过程。

根据这篇文章，以这种方式进行调试有许多限制：

编辑：显然，如果你是制作这个存储过程的人，那么不要让它“许多分层，光标循环，临时表使用，并嵌套”。不过，在我作为 DBA 的角色中，这几乎是我每天从应用程序开发人员那里遇到的情况。

【讨论】：

数据库开发人员可以按照您描述存储过程的方式查看应用程序代码。
如果你认为它写得很糟糕，那肯定很难处理。对于 C# 代码，我会说同样的话——如果开发人员写垃圾，你就会得到垃圾。
我永远不会考虑使用“多层、光标循环、使用临时表、多层嵌套存储过程”。几乎总是有更好的经营方式。我认为 JohnW 的意思是，如果你确实做了这样的事情，那么从定义上来说，对于数据库人员来说，这将是一件坏事。

【解决方案4】：

这个技巧很方便：

【讨论】：

【解决方案5】：

只要不知道有效输入是什么，您就需要测试各种输入，尤其是无效输入。您应该在编写过程之前定义测试用例。然后，您可以在每次有人更改复杂流程时运行一组可重现的测试。

【讨论】：

【解决方案6】：

我的团队按规则使用 SP 作为我们与数据库的接口；我们这样做的方式是应用程序用户只能执行 SP（使用我们的命名约定）。

我们使用的一个效果很好的最佳实践是，某些测试脚本包含在 SP cmets 中，并且必须在 SP 的每个版本或新 SP 的开发中执行。

您应该始终、始终在不涉及任何应用层的情况下尽可能彻底地测试 SP（例如，通过 Management Studio）。

【讨论】：

【解决方案7】：

请务必在VS2005/2008中进入主存储过程，当遇到嵌套函数时，按F11（进入）进入...继续调试...从调试菜单上看不是很明显。

【讨论】：

【解决方案8】：

我不喜欢调试，而是进行测试驱动开发，这几乎不需要调试。

【讨论】：