是的，“一品脱的酒放进半品脱的锅里是不行的”。我对人们建议的各种sp没有太多的运气(无论出于什么原因)，但只要两个表在同一个DB中(或者您可以将它们放到同一个DB中)，您就可以使用INFORMATION_SCHEMA。列来定位错误字段，因此:

select c1.table_name,c1.COLUMN_NAME,c1.DATA_TYPE,c1.CHARACTER_MAXIMUM_LENGTH,c2.table_name,c2.COLUMN_NAME, c2.DATA_TYPE,c2.CHARACTER_MAXIMUM_LENGTH
from [INFORMATION_SCHEMA].[COLUMNS] c1
left join [INFORMATION_SCHEMA].[COLUMNS] c2 on 
c1.COLUMN_NAME=c2.COLUMN_NAME
where c1.TABLE_NAME='MyTable1'
and c2.TABLE_NAME='MyTable2'
--and c1.DATA_TYPE<>c2.DATA_TYPE
--and c1.CHARACTER_MAXIMUM_LENGTH <> c2.CHARACTER_MAXIMUM_LENGTH
order by c1.COLUMN_NAME

这将允许您上下滚动，比较字段的长度。注释的部分可以让您查看(显然是在未注释的情况下)是否存在数据类型不匹配，或者特别显示字段长度不同的数据类型(因为我懒得滚动)，只需注意，所有内容都基于与目标列名匹配的源列名。

问题很简单:源查询中的一个或多个列包含的数据超过了目标列的长度。一个简单的解决方案是使用源查询并在每一列上执行Max(Len(source col))。也就是说,

Select Max(Len(TextCol1))
    , Max(Len(TextCol2))
    , Max(Len(TextCol3))
    , ...
From ...

然后将这些长度与目标表中的数据类型长度进行比较。至少有一个超出了其目标列的长度。

如果你绝对肯定情况不应该是这样，也不关心是不是这样，那么另一个解决方案是强制强制转换源查询列到它们的目标长度(这将截断任何太长的数据):

Select Cast(TextCol1 As varchar(...))
    , Cast(TextCol2 As varchar(...))
    , Cast(TextCol3 As varchar(...))
    , ...
From ...

One other potential reason for this is if you have a default value setup for a column that exceeds the length of the column. It appears someone fat fingered a column that had a length of 5 but the default value exceeded the length of 5. This drove me nuts as I was trying to understand why it wasn't working on any insert, even if all i was inserting was a single column with an integer of 1. Because the default value on the table schema had that violating default value it messed it all up - which I guess brings us to the lesson learned - avoid having tables with default value's in the schema. :)

面对同样的问题。

日志含义源表中的列长度大于目标表中的列长度 源列长度- 50和 目标列长度- nvarchar(25)，并将其增加到nvarchar(50)，并且它工作

当表的列放置约束[主要是长度]时，抛出此错误。例如，如果列myColumn的数据库模式是CHAR(2)，那么当你从任何应用程序调用插入值时，你必须传递长度为2的字符串。

误差基本上说明了这一点;长度为3及以上的字符串不符合数据库模式指定的长度限制。这就是为什么SQL Server警告并抛出数据丢失/截断错误。

至少将数据类型nchar(10)的长度更改为nchar(255)。