我正在开发一个包含大量存储过程的大型项目。我遇到了以下情况:开发人员修改了由另一个存储过程调用的存储过程的参数。 不幸的是,没有什么能阻止ALTER PROC完成。
之后有办法执行这些检查吗? 避免陷入这类问题的准则是什么?
以下是重现此行为的示例代码:
CREATE PROC Test1 @arg1 int
AS
BEGIN
PRINT CONVERT(varchar(32), @arg1)
END
GO
CREATE PROC Test2 @arg1 int
AS
BEGIN
DECLARE @arg int;
SET @arg = @arg1+1;
EXEC Test1 @arg;
END
GO
EXEC Test2 1;
GO
ALTER PROC Test1 @arg1 int, @arg2 int AS
BEGIN
PRINT CONVERT(varchar(32), @arg1)
PRINT CONVERT(varchar(32), @arg2)
END
GO
EXEC Test2 1;
GO
DROP PROC Test2
DROP PROC Test1
GO
答案 0 :(得分:3)
Sql server 2005有一个跟踪依赖关系的系统视图sys.sql_dependencies。不幸的是,它并非完全可靠(有关详细信息,请参阅此answer)。但是,Oracle在这方面要好得多。所以你可以切换。还有第三方供应商Redgate,他有Sql Dependency Tracker。从未测试过,但有试用版。
我遇到了同样的问题所以我通过创建一个存储过程来实现我的穷人解决方案,该存储过程可以搜索当前数据库中所有存储过程和视图中的字符串。通过搜索更改的存储过程的名称,我可以(希望)找到EXEC调用。
我在sql server 2000和2008上使用它,所以它可能也适用于2005.(注意:@word1
,@word2
等必须全部存在,但可以在上一个{ {1}}如果您有不同的需求。)
SELECT
答案 1 :(得分:0)
您可以使用sp_refreshsqlmodule尝试重新验证SP(这也会更新依赖项),但它不会使用调用程序级别的参数验证此特定方案(它将验证表和视图中的无效列等内容)。
http://www.mssqltips.com/tip.asp?tip=1294有许多技巧,包括sp_depends
依赖关系信息存储在SQL Server元数据中,包括每个SP和函数的参数列/类型,但是如何验证所有调用并不明显,但可以找到它们并检查它们。