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

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

如果你使用的是SQL Server 2016-2017: 要修复此问题，请打开跟踪标志460

DBCC TRACEON(460, 1);
GO

确保你在以下情况下将其关闭:

DBCC TRACEOFF(460, 1);
GO

源

我今天遇到了这个问题，在我搜索这个信息量最小的错误消息的答案时，我还发现了这个链接:

https://connect.microsoft.com/SQLServer/feedback/details/339410/please-fix-the-string-or-binary-data-would-be-truncated-message-to-give-the-column-name

所以微软似乎没有计划在短时间内扩展错误信息。

所以我转向了其他方法。

我把错误复制到excel中:

(1行受影响)

(1行受影响)

(1行受影响) 编号8152,16层，14号状态，13行 字符串或二进制数据将被截断。 声明已终止。

(1行受影响)

计算excel中的行数，接近导致问题的记录计数器…调整我的导出代码打印出SQL接近它…然后运行5 - 10个SQL插入问题SQL，并设法查明问题之一，看到字符串太长，增加该列的大小，然后大导入文件运行没有问题。

这是一种破解和变通方法，但当你别无选择时，你只能做你能做的。

我在表创建上使用空字符串，然后在后续更新中接收错误'Msg 8152，字符串或二进制数据将被截断'。发生这种情况是因为更新值包含6个字符，并且比预期的列定义大。我使用“SPACE”来解决这个问题，只是因为我知道我将在初始数据创建后批量更新，即列不会长时间保持空。

这里有个大警告:这不是一个特别巧妙的解决方案，但在你把一个数据集放在一起的情况下很有用，例如，对于一次性的情报请求，你要为数据挖掘创建一个表，应用一些批量处理/解释，并存储结果前后，以便以后比较/挖掘。这是我这一行经常发生的事。

最初可以使用SPACE关键字进行填充。

    select 
           Table1.[column1]
          ,Table1.[column2]
          ,SPACE(10) as column_name
    into table_you_are_creating
    from Table1
    where ...

随后将允许对“column_name”进行10个字符或更少的后续更新(如适用可替换)，而不会导致截断错误。同样，我只会在类似于我的警告中描述的场景中使用它。

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. :)

这里有一个稍微不同的答案。您的列名和长度可能都匹配，但可能您在SELECT语句中以错误的顺序指定了列。假设tableX和tableY的列名称相同，但顺序不同