验证 T-SQL 可编程性对象
有没有办法验证 SQL Server 2008 中的可编程性对象?
我有一个包含约 500 个可编程对象的数据库,这些对象依赖于其他可编程对象(不仅仅是表)。
如果我进行一些重构,则很难找到因更改而损坏的其他对象。例如,如果我更改参数计数...
数据库的原始状态:
CREATE FUNCTION [dbo].[GetSomeText]() RETURNS nvarchar(max) AS BEGIN RETURN 'asdf' END
/* uses "GetSomeText()" function */
CREATE FUNCTION [dbo].[GetOtherText]() RETURNS nvarchar(max) AS BEGIN RETURN [dbo].[GetSomeText]() + '-qwer' END
现在我进行一些重构(将参数 @Num
添加到 GetSomeText()
函数):
ALTER FUNCTION [dbo].[GetSomeText](@Num int) RETURNS nvarchar(max) AS BEGIN RETURN 'asdf' + CAST(@Num as nvarchar(max)) END
现在是函数GetOtherText()
已损坏,因为它在没有必需参数的情况下调用 GetSomeText()
函数。
有没有办法获取有关此错误的信息?
目前,我将每个可编程性对象编写为 ALTER
,运行更改脚本并检查错误。这种方式看起来太复杂(并且很难在仅 T-SQL 环境中使用)。
编辑:
感谢您的回答!我知道如何获取所有对象的依赖项或列表。 问题在于检查对象的主体。如果我获得依赖项,除了运行 ALTER 脚本之外,还有其他方法来检查有效性吗?
Is there a way to validate programmability objects in SQL Server 2008?
I have a database with ~500 programmability objects which depend on other programmability objects (not only tables).
If I do some refactoring, it is very hard find other objects which are broken by the changes. For example if I change the parameter count...
Original state of database:
CREATE FUNCTION [dbo].[GetSomeText]() RETURNS nvarchar(max) AS BEGIN RETURN 'asdf' END
/* uses "GetSomeText()" function */
CREATE FUNCTION [dbo].[GetOtherText]() RETURNS nvarchar(max) AS BEGIN RETURN [dbo].[GetSomeText]() + '-qwer' END
Now I do some refactoring (add parameter @Num
to GetSomeText()
function):
ALTER FUNCTION [dbo].[GetSomeText](@Num int) RETURNS nvarchar(max) AS BEGIN RETURN 'asdf' + CAST(@Num as nvarchar(max)) END
Now the function GetOtherText()
is broken, because it is calling GetSomeText()
function without a required parameter.
Is there a way to get information about this error?
Currently I script every programmability object as ALTER
, run the alter script, and check for errors. This way looks to be too complex (and is hard to use in T-SQL only enviroment).
EDIT:
Thanks for answers! I know how to get dependenices or list of all objects.
The problem is in checking the body of object. If I get the dependency, is there other way to check validity than run ALTER
script?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我认为没有办法找到依赖关系。但是,您可以找到引用您要更改的对象名称的所有内容,如下所示:
o.type in ('P', 'FN')
将搜索限制为 P - 过程和 FN - 标量函数。查看有关 OBJECT_DEFINITION 的更多信息:http://msdn.microsoft.com/en-我们/library/ms176090.aspxI don't think there's a way to find the dependency. You can, however, find everything that references the name of the object you're changing like this:
o.type in ('P', 'FN')
limits the search to P - Procedures and FN - Scalar Functions. Check out more info about OBJECT_DEFINITION: http://msdn.microsoft.com/en-us/library/ms176090.aspx也许您可以尝试引入一些自动化数据库开发人员/单元测试。
对于 500 个 SQL 对象,返回并“重新适应”它们将是一项繁重的工作。最好的方法可能是随着重构/更改现有 API/创建新 SQL 对象的需要而逐步创建这些测试。
然后可以将这些自动化测试作为整体持续集成方法的一部分包含在内。请注意,对于给定的示例,您仍然会遇到查找现有依赖项的问题。但是,一旦有足够的测试覆盖率,测试应该突出显示引入的任何重大更改。
我创建了一个可能有用的测试工具 - 但还有许多其他工具:
http://dbtestunit。 wordpress.com/
Perhaps you could try introducing some automated database developer/unit testing.
With 500 SQL objects it would be onerous to go back and 'retro fit' for them all. Best approach might be to incrementally create these tests as the need to refactor/change existing APIs/create new SQL objects arises
These automated tests could then be included as part of your overall continous integration approach. Note for the example given you would still have the issue of finding existing dependencies. But once there was sufficient test coverage the tests should highlight any breaking changes introduced.
I have created a test tool that might be of use - but there are a number of others out there:
http://dbtestunit.wordpress.com/
获取依赖关系的最简单方法之一是使用
sp_depends
。这确实适用于函数,但您需要确保您处于正确的数据库上下文中:这将向您显示任何对象,无论它是函数、存储过程、表还是具有依赖项的视图对于列出的对象。
不过,对于跨数据库依赖关系,这并不总是准确的,因此请注意。
One of the easiest ways to get dependency is to use
sp_depends
. This does work with functions, but you need to be sure you are in the right DB context:This will show you any object whether it be a function, stored proc, table, or view that has a dependency for the listed object.
This is not always accurate with cross-database dependencies, though, so be aware.