我参与了一个数据迁移项目。当我试图将数据从一个表插入到另一个表(SQL Server 2005)时,我得到以下错误:

编号8152,16层,状态13,1线 字符串或二进制数据将被截断。

源数据列与数据类型匹配,并且在目标表列的长度定义内,因此我不知道是什么原因导致了这个错误。


当前回答

我将添加另一个可能导致这个错误的原因,因为没有人提到过它,它可能会帮助一些未来的人(因为OP已经找到了他的答案)。如果要插入的表有触发器,则可能是触发器正在生成错误。我曾在更改表字段定义时看到过这种情况,但审计表没有更改。

其他回答

当您没有足够的权限时,也会发生这种情况

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

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,并设法查明问题之一,看到字符串太长,增加该列的大小,然后大导入文件运行没有问题。

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

面对同样的问题。

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

SQL Server 2019将最终返回更有意义的错误消息。

二进制或字符串数据将被截断=>错误消息增强 如果您(在生产环境中)出现了该错误,则不太容易看到该错误来自哪一列或哪一行,以及如何准确定位它。

要启用新行为,需要使用DBCC TRACEON(460)。sys.messages中的新错误文本:

SELECT * FROM sys.messages WHERE message_id = 2628

2628 -字符串或二进制数据将在表' %中被截断。*ls ',列' %.*ls '。截断值:' %.*ls '。

字符串或二进制数据将被截断:替换臭名昭著的错误8152

这个新消息也会被反向移植到SQL Server 2017 CU12(以及即将发布的SQL Server 2016 SP2 CU),但不是默认情况下。您需要启用跟踪标志460,以便在会话级别或服务器级别将消息ID 8152替换为2628。 请注意,目前即使在SQL Server 2019 CTP 2.0中也需要启用相同的跟踪标志460。在未来的SQL Server 2019版本中,默认情况下,消息2628将取代消息8152。


SQL Server 2017 CU12也支持该特性。

改进:在SQL Server 2017中用扩展信息替换“字符串或二进制数据将被截断”消息

此SQL Server 2017更新引入了一条可选消息,其中包含以下附加上下文信息。 Msg 2628,级别16,状态6,程序程序命名,行Linenumber 字符串或二进制数据将在表'%中被截断。*ls',列'%.*ls'。 截断值:'%.*ls'。 新的消息ID是2628。如果启用了跟踪标志460,此消息将替换任何错误输出中的消息8152。

db < > fiddle演示


ALTER DATABASE SCOPED CONFIGURATION VERBOSE_TRUNCATION_WARNINGS = { ON | OFF } APPLIES TO: SQL Server (Starting with SQL Server 2019 (15.x)) and Azure SQL Database Allows you to enable or disable the new String or binary data would be truncated error message. SQL Server 2019 (15.x) introduces a new, more specific error message (2628) for this scenario: String or binary data would be truncated in table '%.*ls', column'%.*ls'. Truncated value: '%.*ls'. When set to ON under database compatibility level 150, truncation errors raise the new error message 2628 to provide more context and simplify the troubleshooting process. When set to OFF under database compatibility level 150, truncation errors raise the previous error message 8152. For database compatibility level 140 or lower, error message 2628 remains an opt-in error message that requires trace flag 460 to be enabled, and this database scoped configuration has no effect.

我也遇到过类似的问题。我将数据从一个表复制到一个完全相同的表,除了名称。

最后,我使用SELECT into语句将源表转储到临时表中。

SELECT *
INTO TEMP_TABLE
FROM SOURCE_TABLE;

我比较了源表和临时表的模式。我发现其中一列是varchar(4000),而我期待的是varchar(250)。

更新: 如果你感兴趣,varchar(4000)问题可以在这里解释:

对于Nvarchar(Max),我只能在TSQL中获得4000个字符?

希望这能有所帮助。