跨链接服务器复制表数据报错：SQLNCLI11返回无效列数据

看起来你在跨服务器复制大表数据时碰到了挺头疼的问题——SQLNCLI11提供器返回无效数据，哪怕指定列也没用。结合你的情况，我整理了几个排查和解决的方向，你可以一步步试：

1. 先确认列的底层数据类型完全匹配 #

虽然你说表结构一致，但有时候表面上的“一致”可能藏着细节差异，这是这类报错的常见原因：

• 检查GDTXVC列是不是两边都是同类型（比如varchar vs nvarchar很容易踩坑），长度、排序规则（Collation）是否完全相同
• 有没有一边是text/ntext这类旧类型？这类类型在链接服务器查询中兼容性很差

你可以在两个库分别执行这个查询，对比结果：

SELECT 
    COLUMN_NAME, 
    DATA_TYPE, 
    CHARACTER_MAXIMUM_LENGTH, 
    COLLATION_NAME
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'TABLE' 
  AND COLUMN_NAME = 'GDTXVC'

2. 定位是否存在脏数据 #

300多万行里大概率有个别行的数据不符合类型定义，比如：

• varchar列里混了二进制字符或者超出编码范围的内容
• 实际数据长度超过了列定义的长度（某些特殊场景下可能存在这种情况）

你可以分批查询来锁定问题行：

-- 先试前1000行，看会不会报错
SELECT GDTXVC FROM [Server].[DATABASE].[SCHEMA].[TABLE] TOP 1000

-- 如果没问题，按主键分段查，比如主键是ID的话
SELECT GDTXVC FROM [Server].[DATABASE].[SCHEMA].[TABLE] WHERE ID BETWEEN 1 AND 100000

找到报错的批次后，再缩小范围定位到具体行，然后清理或者修正那行的数据。

3. 调整链接服务器的提供器设置 #

SQLNCLI11的默认设置有时候会导致这类兼容性问题，你可以试试开启“允许进程内”选项：

1. 打开SSMS，找到你的链接服务器ServerName
2. 右键→属性→切换到「提供器选项」标签
3. 勾选允许进程内（Allow inprocess），保存后重新测试查询

4. 换用更稳定的批量复制方式 #

如果以上方法都没解决，不如绕开链接服务器的直接查询，用更可靠的工具：

• 用bcp命令行工具导出源表数据，再导入目标库，这个工具对大表数据的处理很高效
• 用SSIS创建数据流动任务，直接读取源表写入目标表，SSIS能更好地处理数据类型转换，还能设置错误行的处理规则，不会因为个别行失败导致整个复制任务卡壳

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