【问题标题】:"Conversion failed because the data value overflowed the specified type" error applies to only one column of the same table“转换失败,因为数据值溢出指定类型”错误仅适用于同一张表的一列
【发布时间】:2017-03-13 22:49:54
【问题描述】:

我正在尝试将数据从数据库访问文件导入 SQL 服务器。为此,我通过 SQL Server 导入/导出向导创建了 SSIS 包。当我通过执行包实用程序执行包并选中“不执行验证”选项时,所有表都已通过验证。但是,在执行过程中,我收到了以下错误信息(使用图片,因为 blockquote 占用了大量空间):

经过调查,我准确地找到了导致问题的表和列。但是,这是我几天来一直在尝试解决的问题,而且我对可能的选择感到无所适从。

问题表列的结构

如错误列表中所述,故障发生在“返回日期”列的 RHF 维修表中。在 Access 中,有问题的列是日期/时间类型。在实际表格中,所有输入都是“mmddyy”的形式,点击后会变成“mm/dd/yyyy”格式:

在 SSIS 包中,它创建了 OLEDB 源/目标关系,如下所示:

在这种关系中,输出列和外部列中的数据类型都是 DT_DATE(我仍然认为这是我的问题的关键原因)。最让我烦恼的是,与返回日期相邻的列与我上面描述的完全相同,并且没有任何错误应用于它或任何其他相同类型的列,返回日期实际上是唯一的害群之马羊群。

我尝试了什么

我已经尝试了以下thread中的每个选项,错误仍然存​​在。

我尝试了数据转换选项,试图将此列转换为日期戳甚至 unicode 字符串。没用。

我尝试使用高级源代码编辑器为日期戳/unicode 字符串指定数据类型。我尝试仅在输出列中指定它,在外部列和输出列中都尝试过,结果相同。

浏览访问表中的数据也没有给我任何东西。它们都使用相同的 6 字符格式。

在这一点上,我真的用尽了我能想到的所有选择。 能否请您指出我还可以尝试解决的正确方向,因为过去两天这让我发疯。

PS:最后,我会单独浏览每一行,同时不会因为有 4000 多个行条目而气馁……

更新:

我通过浏览数据解决了这个问题。在 4000 多行中有 3 个错误条目...由于问题的解决方式不太可能帮助其他人,请关闭该问题。

【问题讨论】:

  • 也许您应该在 Access 中编写 CREATE TABLE 语句(如果可能的话;我对此了解不多)并将其与 SQL Server 中的 create table 语句进行比较?此外,可能是 SQL Server 和 Access 之间的区域设置差异吗?也许摆弄SET DATEFORMAT?还是SET LANGUAGE
  • @TT。谢谢,我一定会尝试所有建议...
  • 您应该配置数据转换组件以将错误行重定向到不同的输出,看看这个learnmsbitutorials.net/…

标签: sql-server date ssis sql-server-2012 data-conversion


【解决方案1】:

在我看来,您的专栏中有一个或多个糟糕的日期。有 4,000 行,我实际上会在视觉上扫描并寻找非常短或非常长的东西。

您可以将来源更改为选择前 1 个而不是全部 4,000 个。那些插入?如果是这样,那将加重糟糕的约会情况。如果1行没有流过,那就是另外一个问题了。

【讨论】:

  • 4000+ 行中有 3 个错误条目... >_
  • 典型的访问权限。我在日期列中发现了像“03462”这样的数据。啊。
  • 在这里,问题结束前的一些免费奖金。
【解决方案2】:

(我只会分享我的经验,我是如何克服这个问题的,以防它对某人有所帮助)

我的场景:

ole db 数据源中的列Identifier 已从int 更改为bigint。我收到错误消息 - 转换失败,因为数据值溢出了指定的类型。

基本上,它告诉我源数据大小大于目标数据大小。

我尝试过的:

在ole db数据源和目标两个地方,我点击“显示高级编辑器”,检查数据类型标识符是bigint。但是,我仍然收到错误消息

解决方案对我有用:

ole db数据源-->显示高级版选项-->输入输出属性-->OLE DB源输出-->有两个选项--外部列和输出列。

在我的例子中,虽然外部列中的标识符列显示数据类型 bigint,但输出列中显示数据类型 int。因此,我将数据类型更改为 bigint,它解决了我的问题。

我时不时会遇到这个问题,特别是当我有一个包含大量数据的大表时。

我希望它有所帮助。

【讨论】:

  • 我更改了 ETL 查询将变量从 DECIMAL(10,2) 转换为 DECIMAL(25,4) 的方式,并且额外的精度导致了这个错误。这个答案的修复适用于这种情况。
【解决方案3】:

当有人将年份输入为 216 而不是 2016 时,我们遇到了此错误。数据源读取数据正常,但在 OLEDB 目标任务上失败。 我们在数据流中使用脚本任务进行验证。通过添加一个检查以确保过去的日期不会太远,我们能够捕获此类错误并至少生成有意义的错误消息以快速找到并纠正问题。

【讨论】:

    猜你喜欢
    • 2019-06-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-12-31
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多