正如其他人已经说过的，源表中的某个列数据类型大于目标列。

一个简单的解决方案是关闭警告并允许发生截断。所以，如果你收到这个错误，但你确定它是可以接受的数据在你的旧数据库/表被截断(削减到大小)，你可以简单地做以下事情;

SET ANSI_WARNINGS OFF;
-- Your insert TSQL here.
SET ANSI_WARNINGS ON;

如上所述，始终记得在结束后再次打开警告。

这可能是一个具有挑战性的错误。以下是AmirCharania在https://connect.microsoft.com/SQLServer/feedback/details/339410/网站上发表的评论。

我调整了AmirCharania给出的答案，用于选择实际表中的数据，而不是临时表。首先选择你的数据集到一个开发表中，然后运行以下命令:

WITH CTE_Dev
AS (
    SELECT C.column_id
        ,ColumnName = C.NAME
        ,C.max_length
        ,C.user_type_id
        ,C.precision
        ,C.scale
        ,DataTypeName = T.NAME
    FROM sys.columns C
    INNER JOIN sys.types T ON T.user_type_id = C.user_type_id
    WHERE OBJECT_ID = OBJECT_ID('YOUR TARGET TABLE NAME HERE, WITH SCHEMA')
    )
    ,CTE_Temp
AS (
    SELECT C.column_id
        ,ColumnName = C.NAME
        ,C.max_length
        ,C.user_type_id
        ,C.precision
        ,C.scale
        ,DataTypeName = T.NAME
    FROM sys.columns C
    INNER JOIN sys.types T ON T.user_type_id = C.user_type_id
    WHERE OBJECT_ID = OBJECT_ID('YOUR TEMP TABLE NAME HERE, WITH SCHEMA')
    )
SELECT *
FROM CTE_Dev D
FULL OUTER JOIN CTE_Temp T ON D.ColumnName = T.ColumnName
WHERE ISNULL(D.max_length, 0) < ISNULL(T.max_length, 999)

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

对于其他的，也检查您的存储过程。在我的例子中，在我的存储过程CustomSearch中，我不小心声明了我的列没有足够的长度，所以当我输入一个大数据时，我收到了这个错误，尽管我的数据库中有很大的长度。我只是在自定义搜索中改变了列的长度错误就消失了。这只是为了提醒大家。谢谢。

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

我在表创建上使用空字符串，然后在后续更新中接收错误'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个字符或更少的后续更新(如适用可替换)，而不会导致截断错误。同样，我只会在类似于我的警告中描述的场景中使用它。