我有一个最初由有人说，没有足够的时间来正确地设计它写在我的生产环境中的存储过程。这是写有9个或更多加入到跨链接服务器连接的数据库。
该存储过程正在采取一个多小时运行。大约一年半前，我重新设计了它（设计吗？）更有效地访问数据，现在存储过程不仅使整个连接服务器2个不同的电话。运行时间降到了这些更改后不到5分钟。
大约6个月后（和督促发布后的第二天）的存储过程的性能是回到了一个多小时运行。当我看到这个存储过程（右键单击，修改）的代码已经恢复旧蹩脚的代码。
没有人能够访问运行ALTER PROCEDURE会承认自己改变了它，所以我做了任何理性的信任DBA会做 - 我再次固定，并把一个DDL审计触发器对生产数据库来跟踪生产的任何和所有DDL更改。
大约6个月后，蹩脚的代码又回来了，一个督促发布后一天。在DDL审计表的检查显示没有触及存储过程。我固定的存储过程和修复事件的DDL审计表中显示出来。 W.T.H。??
我们通过使用Visual Studio做一个架构测试和督促之间的比较，然后生成一个脚本建立我们的分贝释放脚本。所生成的脚本的一部分是几
EXECUTE sp_refreshsqlmodule N'[dbo].[db object here]';
调用。在接下来的几个版本我确保没有sp_refreshsqlmodule对于违规的存储过程的执行 - 我们有没有问题。然后我出去释放和备份DBA并没有消除sp_refreshsqlmodule电话 - 糟糕的代码没有DDL审计记录返回。
我们的生产服务器与地方正确的代码被硬启动几次。凡/如何/什么是sp_refreshsqlmodule做来获得存储过程的旧副本，奠定它在良好的副本？如何强制存储过程的版本好进入这个神奇的藏身之处？
我从来没有过这个问题，不过我已经听到有人时，他们使用ALTER命令（13759修改）修改了存储过程中的问题谁了这个问题。当他们做了删除并创建代替，这个问题就走了。