Pentaho 表输出步骤未在日志中显示正确的错误答案

【问题标题】：Pentaho table output step not showing proper error in logPentaho 表输出步骤未在日志中显示正确的错误
【发布时间】：2014-01-24 22:45:51
【问题描述】：

在 Pentaho 中，我有一个表输出步骤，我将大量记录加载到 netezza 目标表中。

其中一行失败，日志显示导致问题的值。但是日志可能不正确，因为当我使用这些值创建一个插入语句并在数据库上单独运行它时，它工作正常。

我的问题是：在 Pentaho 中，有没有办法确定当 db insert 失败时，究竟是哪些值导致了问题以及为什么？

编辑：错误是“超出列宽”，它向我显示了可能导致问题的值。但是我用这些值做了一个插入语句，效果很好。所以我认为 Pentaho 没有向我显示正确的错误消息，它是导致问题的一组不同的值。

【问题讨论】：

我猜你的输入集中有重复的值。因此，您加载了一个键值，然后在一堆行之后您尝试加载相同的值，并得到一个重复的键错误。如果是这种情况，并且您无法从输入集中获取重复数据，则可以使用Unique Values 步骤将它们过滤掉。如果您的“问题”不是重复键错误，请发布它是什么。
谢谢，你能看看我的编辑，看看它是否有助于调试。
听起来像@carexcer 就在上面。如果您发布您尝试加载的表的 DDL，这也会很有帮助。当您“使用这些值创建和插入语句”时，您是否直接从错误日志中复制了这些值？

标签： pentaho netezza

【解决方案1】：

我用来处理这类问题的另一种方法是在数据库中创建另一个具有扩展列类型的表。然后在您的转换中，添加一个连接到新表的Table output 步骤。然后将您原来的 Table output 连接到新步骤，但在询问时，选择“错误处理”作为跃点类型。

当您运行转换时，有问题的行最终会出现在新表中。然后，您可以准确调查该特定行的问题所在。

例如，您可以执行以下操作：

insert into [original table] select * from [error table];

与从 JDBC 驱动程序相比，您可能会从本机 DB 接口获得更好的错误消息。

【讨论】：

好主意，我星期一第一件事就试试
如果需要，您可以做的另一件事是在转换的上游放置一个序列计数器，并在错误表中添加一个列来存储它。然后，当该行到达您的错误表时，您就可以确切地知道输入集中的哪一个正在中断。

【解决方案2】：

我不知道你到底是什么问题，但我想我以前也遇到过同样的问题。

一切似乎都是正确的，但问题是在某些转换中，例如，当我将数值转换为字符串时，转换在字段末尾添加了一个空格，而字段的 long 是 n+1的n，但很难看到。

一个实际的例子是，如果您使用计算器步骤进行转换，您可以使用YEAR() 函数来提取日期字段的年份，并且可能在带有年份的新字段中添加了一个空格，所以如果年份的长度为 4，在该步骤之后长度为 5，当您要将一行（该年份字段为 string(5)）加载到数据仓库中时，您的数据仓库是期待string(4)，您将得到与现在相同的错误。

You think is happening --> year = "2013"   --> length 4
Really is happening    --> year = "2013 "  --> length 5

我建议您非常注意字符串字段及其长度，因为如果某些转换添加了空格，您不会想到会丢失很多找到错误的时间（我自己的经验）。

希望对你有用！

编辑：我猜您正在使用 PDI（Spoon，在 Kettle 之前），并且在您加载数据仓库时会产生错误，所以如果我错了，请纠正我。

【讨论】：

谢谢，我检查了每个字段，我认为在日志中显示为“问题值”的值不是问题。导致问题的实际值未显示在日志中。
能否提供提供日志的完整错误信息？可能您是对的，但是如果我看到完整的错误消息，我可以为您提供更多帮助。如果你能提供你正在使用的步骤会更好，因为一些步骤转换有问题，有时需要使用替代方法来做一些事情
非常感谢，我会这样做的。再次感谢伙计，感谢您的帮助。

【解决方案3】：

你能不能用 nzload 命令来使用这个文件，通过这个命令你可以找到准确的错误，以及你提供的 badFile 中的坏记录，以便详细分析。

例如-

nzload -u <username> -pw <password> -host <netezzahost> -db <database> -t <tablename> -df <datafile> -lf <logfile> -bf <badrecords file name> -delim <delimiter>

【讨论】：