同版本SQL Server修改列大小Win8正常Win10报依赖错误求助

首先得明确核心问题：虽然两台机器装的是同版本SQL Server，但Win10机器上的myAddress表存在额外的依赖对象（默认约束defEmptyString、两个索引），而Win8机器上的表没有这些依赖——这才是报错的根本原因，和Windows版本关系不大，大概率是两台机器的数据库环境不一样。

给你几个具体的排查和解决方向：

1. 确认数据库环境的差异 #

先在Win10机器上查清楚myTown列的所有依赖对象，对比Win8机器的表状态：

• 执行这个查询，列出所有依赖myTown的对象：

  SELECT 
      o.name AS dependent_object,
      o.type_desc AS object_type
  FROM sys.objects o
  JOIN sys.sql_expression_dependencies sed 
      ON o.object_id = sed.referencing_id
  JOIN sys.columns c 
      ON sed.referenced_id = c.object_id 
      AND sed.referenced_minor_id = c.column_id
  WHERE c.object_id = OBJECT_ID('myAddress') 
      AND c.name = 'myTown';
  

如果Win8机器上执行这个查询没有结果，说明Win10机器的数据库里，myAddress表在执行ALTER COLUMN前已经被创建了那些约束和索引——可能是之前执行脚本的残留，或者脚本执行顺序有误。

解决办法：把Win10机器上的目标数据库清空（或者新建一个空库），再从头执行团队的脚本。如果脚本本身是先创建表、再ALTER COLUMN、最后创建约束/索引，那全新环境下应该和Win8机器一样不会报错。

2. 检查数据库兼容级别 #

SQL Server的兼容级别会影响部分DDL语句的行为，确认两台机器的数据库兼容级别一致：

• 执行查询：

  SELECT name, compatibility_level 
  FROM sys.databases 
  WHERE name = '你的数据库名称';
  

SQL Server 2016的默认兼容级别是130，如果Win10机器的数据库设成了更低的级别（比如120对应2014），可能会导致依赖检查更严格。如果不一致，改成130试试：

ALTER DATABASE 你的数据库名称 
SET COMPATIBILITY_LEVEL = 130;

3. 统一会话的SET选项 #

执行DDL时的会话SET选项差异也可能导致不同行为，确保两台机器执行脚本时的SET选项一致。可以在团队脚本开头加上统一的配置：

SET ANSI_NULLS ON;
SET QUOTED_IDENTIFIER ON;
SET ANSI_PADDING ON;
SET ANSI_WARNINGS ON;
SET CONCAT_NULL_YIELDS_NULL ON;

这些是SQL Server推荐的DDL执行默认选项，避免因环境默认配置不同导致的问题。

4. 前置处理依赖对象（如果不能清空数据库） #

如果Win10机器的数据库不能清空，又必须用原脚本执行，可以先手动删除依赖对象，执行完ALTER COLUMN后再重建：

-- 先删除默认约束
ALTER TABLE myAddress DROP CONSTRAINT defEmptyString;

-- 删除依赖索引
DROP INDEX IX_myAddress_Name_Town ON myAddress;
DROP INDEX IX_myAddress_Town ON myAddress;

-- 执行原脚本的ALTER COLUMN语句
ALTER TABLE myAddress ALTER COLUMN myTown nvarchar(100) NOT NULL;

-- 重建默认约束
ALTER TABLE myAddress ADD CONSTRAINT defEmptyString DEFAULT '' FOR myTown;

-- 重建索引（根据实际索引定义调整）
CREATE NONCLUSTERED INDEX IX_myAddress_Name_Town 
ON myAddress (你的其他列名, myTown);

CREATE NONCLUSTERED INDEX IX_myAddress_Town 
ON myAddress (myTown);

把这些步骤做成一个前置脚本，在执行团队原脚本前运行，就能绕过依赖报错的问题。

5. 检查SQL Server补丁一致性 #

最后确认两台机器的SQL Server 2016 SP1是否安装了相同的累积更新（CU）。有些CU会修复DDL相关的行为差异，如果Win10机器的补丁更旧或更新，可能导致执行结果不同。可以通过SELECT @@VERSION查看详细版本号，对比两台机器的差异。

内容的提问来源于stack exchange，提问作者Samurai Jack