如何在架构更改后检测损坏的存储过程？

Question

我修改了数据库中的一个中央表，sp_depends 确实返回了数百个结果，我担心其中一些存储过程在我更改后可能不再编译。

检查单个存储过程很容易（我只是重新运行alter 脚本并查看操作是否成功），但是对100 多个过程执行此操作有点麻烦。

我知道我可以使用脚本像这样一个重新编译我的数据库中的所有对象，但实际操作中会发生下一次的存储过程执行，而不是立即，这样似乎并不在我的情况适合。

我还想我可以完全删除所有的存储过程，并用我的源代码控制系统重新同步我的数据库，但是这个选项虽然可行，但不是很优雅。有没有更好的方法来做到这一点？

我使用的是 SQLServer 2008 R2，我的数据库脚本存储在 VS 2008 数据库项目中。

澄清一下，我并不是主张人们应该仅仅依靠这种方法来测试代码。就像在 c# 中一样，您在编写代码时会立即检测其他依赖文件中的语法错误（然后使用其他策略进行测试，例如单元测试，这通常会慢几个数量级），我认为检测 SQL 依赖关系是有意义的在几秒钟内出错，而不必运行通常需要几个小时才能完成的完整功能测试。

Answer 1

您如何运行您的单元、功能、集成和性能测试？如果您没有任何测试，那么是时候开始将您的数据库模式视为代码并将其视为代码，包括版本控制和测试。Alex Kuznetsov 有一整本书专门讨论这个主题：使用 SQL Server 进行防御性数据库编程。

不幸的是，目前 SQL Server 的最先进技术与存储过程中的相关依赖检测“严重受损”，请参阅 [了解 SQL 依赖关系](http://technet.microsoft.com/en-us/library/ms345449 %28v=sql.105%29.aspx) 或 [在 SQL Server 2008 中保持 sysdepends 最新](http://sqlblog.com/blogs/aaron_bertrand/archive/2008/09/09/keeping-sysdepends-up- to-date-in-sql-server-2008.aspx）。甚至有[第三方工具试图解决这个问题](http://www.red-gate.com/products/sql-development/sql-dependency-tracker/) (2认同)
这使得单元/功能测试几乎成为检测重大更改的唯一可靠方法。 (2认同)

Answer 2

这是一个解决方法，但您可以为数据库生成 CREATE PROCEDURE 脚本（右键单击数据库 -> 任务 -> 生成脚本），找到 CREATE PROCEDURE 并将其替换为 ALTER PROCEDURE，然后解析。

我希望你在这里得到更好的答案 - 我也感兴趣！:)