如何修改存在数十个依赖项的SQL Server函数？

现状说明 #

SQL Server中，即便你仅修改函数的内部计算逻辑、完全保留输入参数与返回结果的公共接口，只要存在默认约束依赖该函数，执行ALTER FUNCTION时仍会触发报错，阻止修改操作。这是因为默认约束属于函数的架构绑定依赖项，SQL Server会强制校验依赖关系的有效性。

可行解决方案（无需手动逐个处理依赖约束） #

目前SQL Server（包括最新版本）并未提供直接跳过依赖检查的ALTER FUNCTION命令修饰符，但可以通过动态SQL脚本自动完成删除依赖约束→修改函数→重建约束的流程，无需手动操作数十个依赖项：

1. 生成并执行自动处理脚本
   以下脚本会自动识别所有依赖目标函数的默认约束，生成删除和重建约束的语句，再执行修改函数的操作：

   DECLARE @FuncName NVARCHAR(128) = 'dbo.你的目标函数名'; -- 替换为你的函数（含 schema）
   DECLARE @DropConstraintsSQL NVARCHAR(MAX) = '';
   DECLARE @RecreateConstraintsSQL NVARCHAR(MAX) = '';
   
   -- 生成删除依赖默认约束的脚本
   SELECT 
       @DropConstraintsSQL += 'ALTER TABLE ' 
       + QUOTENAME(OBJECT_SCHEMA_NAME(dc.parent_object_id)) + '.' + QUOTENAME(OBJECT_NAME(dc.parent_object_id)) 
       + ' DROP CONSTRAINT ' + QUOTENAME(dc.name) + ';' + CHAR(13)
   FROM sys.default_constraints dc
   JOIN sys.sql_expression_dependencies sed 
       ON dc.object_id = sed.referencing_id
   WHERE sed.referenced_id = OBJECT_ID(@FuncName);
   
   -- 生成重建默认约束的脚本
   SELECT 
       @RecreateConstraintsSQL += 'ALTER TABLE ' 
       + QUOTENAME(OBJECT_SCHEMA_NAME(dc.parent_object_id)) + '.' + QUOTENAME(OBJECT_NAME(dc.parent_object_id)) 
       + ' ADD CONSTRAINT ' + QUOTENAME(dc.name) + ' DEFAULT ' + dc.definition + ' FOR ' + QUOTENAME(c.name) + ';' + CHAR(13)
   FROM sys.default_constraints dc
   JOIN sys.sql_expression_dependencies sed 
       ON dc.object_id = sed.referencing_id
   JOIN sys.columns c 
       ON dc.parent_object_id = c.object_id AND dc.parent_column_id = c.column_id
   WHERE sed.referenced_id = OBJECT_ID(@FuncName);
   
   -- 执行删除约束
   IF @DropConstraintsSQL <> ''
       EXEC sp_executesql @DropConstraintsSQL;
   
   -- 执行函数修改（替换为你的ALTER FUNCTION语句）
   ALTER FUNCTION dbo.你的目标函数名(/* 原输入参数 */)
   RETURNS /* 原返回类型 */
   AS
   BEGIN
       -- 你的新内部计算逻辑
   END;
   
   -- 执行重建约束
   IF @RecreateConstraintsSQL <> ''
       EXEC sp_executesql @RecreateConstraintsSQL;
   

2. 脚本说明

   • 脚本会自动遍历系统视图，找出所有依赖目标函数的默认约束；
   • 先删除这些约束，再执行函数修改；
   • 最后用原约束定义重建所有默认约束，确保业务逻辑不受影响。

注意事项 #

• 执行脚本前建议备份数据库，或在测试环境验证后再部署到生产；
• 如果函数还存在其他类型的依赖项（如视图、存储过程），可扩展脚本逻辑，同样通过系统视图识别并处理。

内容的提问来源于stack exchange，提问作者Marc Guillot