我参与了一个数据迁移项目。当我试图将数据从一个表插入到另一个表(SQL Server 2005)时,我得到以下错误:
编号8152,16层,状态13,1线 字符串或二进制数据将被截断。
源数据列与数据类型匹配,并且在目标表列的长度定义内,因此我不知道是什么原因导致了这个错误。
我参与了一个数据迁移项目。当我试图将数据从一个表插入到另一个表(SQL Server 2005)时,我得到以下错误:
编号8152,16层,状态13,1线 字符串或二进制数据将被截断。
源数据列与数据类型匹配,并且在目标表列的长度定义内,因此我不知道是什么原因导致了这个错误。
当前回答
我在表创建上使用空字符串,然后在后续更新中接收错误'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. :)
我在表创建上使用空字符串,然后在后续更新中接收错误'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个字符或更少的后续更新(如适用可替换),而不会导致截断错误。同样,我只会在类似于我的警告中描述的场景中使用它。
问题很简单:源查询中的一个或多个列包含的数据超过了目标列的长度。一个简单的解决方案是使用源查询并在每一列上执行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 ...
这里有一个稍微不同的答案。您的列名和长度可能都匹配,但可能您在SELECT语句中以错误的顺序指定了列。假设tableX和tableY的列名称相同,但顺序不同
是的,我也面临着这样的问题。
REMARKS VARCHAR(500)
to
REMARKS VARCHAR(1000)
在这里,我将备注文件的长度从500更改为1000