我参与了一个数据迁移项目。当我试图将数据从一个表插入到另一个表(SQL Server 2005)时,我得到以下错误:
编号8152,16层,状态13,1线 字符串或二进制数据将被截断。
源数据列与数据类型匹配,并且在目标表列的长度定义内,因此我不知道是什么原因导致了这个错误。
我参与了一个数据迁移项目。当我试图将数据从一个表插入到另一个表(SQL Server 2005)时,我得到以下错误:
编号8152,16层,状态13,1线 字符串或二进制数据将被截断。
源数据列与数据类型匹配,并且在目标表列的长度定义内,因此我不知道是什么原因导致了这个错误。
当前回答
是的,“一品脱的酒放进半品脱的锅里是不行的”。我对人们建议的各种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
这将允许您上下滚动,比较字段的长度。注释的部分可以让您查看(显然是在未注释的情况下)是否存在数据类型不匹配,或者特别显示字段长度不同的数据类型(因为我懒得滚动),只需注意,所有内容都基于与目标列名匹配的源列名。
其他回答
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. :)
请尝试以下代码:
CREATE TABLE [dbo].[Department](
[Department_name] char(10) NULL
)
INSERT INTO [dbo].[Department]([Department_name]) VALUES ('Family Medicine')
--error will occur
ALTER TABLE [Department] ALTER COLUMN [Department_name] char(50)
INSERT INTO [dbo].[Department]([Department_name]) VALUES ('Family Medicine')
select * from [Department]
我今天遇到了这个问题,在我搜索这个信息量最小的错误消息的答案时,我还发现了这个链接:
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,并设法查明问题之一,看到字符串太长,增加该列的大小,然后大导入文件运行没有问题。
这是一种破解和变通方法,但当你别无选择时,你只能做你能做的。
我也遇到过类似的问题。我将数据从一个表复制到一个完全相同的表,除了名称。
最后,我使用SELECT into语句将源表转储到临时表中。
SELECT *
INTO TEMP_TABLE
FROM SOURCE_TABLE;
我比较了源表和临时表的模式。我发现其中一列是varchar(4000),而我期待的是varchar(250)。
更新: 如果你感兴趣,varchar(4000)问题可以在这里解释:
对于Nvarchar(Max),我只能在TSQL中获得4000个字符?
希望这能有所帮助。
在Acumatica ERP中,我在导入订单时得到了相同的错误。
字符串或二进制数据将被截断在表'MyDatabase.dbo。ARInvoice',列'InvoiceNbr'。截断值“Something”。
在做了这个链接中描述的步骤如何修复字符串或二进制截断错误后,我得到了另一个错误“数量将变成负数”,这是通过在收据屏幕中创建一些数量来解决的。