不,它不会记录在任何地方。投票并陈述您的业务案例;这是SQL Server应该修复的一长串内容之一。
这是几年前在Connect上提出的(可能首先是在SQL Server 2000或2005的时间范围内),然后在新的反馈系统上再次提出:
现在已在SQL Server 2019,SQL Server 2017 CU12中交付,并将在以后的SQL Server 2016 SP2 CU中出现。
在SQL Server 2019的第一个公共CTP中,它仅在跟踪标志460下浮出水面。这听起来有些秘密,但已在此Microsoft白皮书中发布。尽管您将能够通过新的数据库作用域配置来控制此行为,但这将是默认行为(无需跟踪标志)VERBOSE_TRUNCATION_WARNINGS
。
这是一个例子:
USE tempdb;
GO
CREATE TABLE dbo.x(a char(1));
INSERT dbo.x(a) VALUES('foo');
GO
结果是SQL Server 2019之前的所有受支持版本:
消息8152,级别16,状态30,第5行
字符串或二进制数据将被截断。
该语句已终止。
现在,在SQL Server 2019 CTP上,启用了跟踪标志:
DBCC TRACEON(460);
GO
INSERT dbo.x(a) VALUES('foo');
GO
DROP TABLE dbo.x;
DBCC TRACEOFF(460);
结果显示表,列和(截断的,不完整的)值:
消息2628,级别16,状态1,第11
行在表'tempdb.dbo.x'的列'a'中,字符串或二进制数据将被截断。截断值:“ f”。
该语句已终止。
在删除所有内容并升级到SQL Server 2019或移动到Azure SQL数据库之前,可以更改“自动”代码以实际从中拉出max_length sys.columns
以及无论如何必须到达的名称,然后应用LEFT(column, max_length)
或不管PG的等价物是什么。或者,由于这仅意味着您将无声地丢失数据,因此请找出哪些列不匹配并修复目标列,以使它们适合源中的所有数据。给定元数据访问这两个系统的权限,并且您已经在编写一个必须与源->目标列自动匹配的查询(否则,该错误几乎不是您的最大问题),您不必进行任何暴力操作完全在猜测。
sys.columns
因为我完全不知道您当前使用什么代码来“自动”生成查询。关于合并到您的代码中,我想不到的真的没有什么要复杂的SELECT name, object_id, max_length FROM sys.columns;
。由于您已经具有必须执行此操作的自动代码-或类似的代码-我认为没有必要提供示例。