DatabaseLookup 挂在特定值上
我使用 Kettle 进行一些转换并遇到了问题： 对于某一特定行，我的 DatabaseLookup 步骤挂起。它只是没有给出结果。尝试停止转换会导致查找步骤永无止境的“停止”。
给定的值一点也不复杂，它与所有其他行/值也没有什么不同。它只是不会继续下去。
直接在数据库中或在不同的数据库工具（例如SQuirreL）中执行相同的查询，它可以工作。
我使用Kettle/Spoon 4.1，数据库是MySQL 5.5.10。 Connector/J 5.1.14 和与勺子捆绑在一起的产品会发生这种情况。
该步骤完美地初始化（它甚至适用于其他行），我不知道为什么它会失败。 Spoon 日志中没有错误消息，控制台/shell 上也没有任何错误消息。
I use Kettle for some transformations and ran into a problem:
For one specific row, my DatabaseLookup step hangs. It just doesn't give a result. Trying to stop the transformation results in a never ending "Halting" for the lookup step.
The value given is nothing complicated at all, neither it is different from all other rows/values. It just won't continue.
Doing the same query in the database directly or in a different database tool (e.g. SQuirreL), it works.
I use Kettle/Spoon 4.1, the database is MySQL 5.5.10. It happens with Connector/J 5.1.14 and the one bundled with spoon.
The step initializes flawlessly (it even works for other rows) and I have no idea why it fails. No error message in the Spoon logs, nothing on the console/shell.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
诡异的。桌子类型是什么？是myisam吗？您的转换是否也对同一个表执行更新？也许您不知何故同时无意中锁定了表？
或者也许这是 mysql 5.5 的事情..但是我在 mysql 5.0 和 pdi 4 中广泛使用了这个步骤。一切都很好......也许发布转换？
weird. Whats the table type? is it myisam? Does your transform also perform updates to the same table? maybe you are locking the table inadvertantly at the same time somehow?
Or maybe it's a mysql 5.5 thing.. But ive used this step extensively with mysql 5.0 and pdi 4.everything and it's always been fine... maybe post the transform?
我刚刚找到了罪魁祸首：
查找的结果是 id 字段并为其指定一个新名称 PERSON_ID。在某些情况下这会失败！生成的查找/准备语句类似于
解决方案：
不要在字段的“新名称”中使用下划线！使用新名称 PERSONID 后，所有 行的一切都可以完美运行！
愚蠢的错误...
I just found the culprit:
The lookup takes as a result the id field and gave it a new name, PERSON_ID. This FAILS in some cases! The resulting lookup/prepared statement was something like
SOLUTION:
Don't use underscore in the "New name" for the field! With a new name of PERSONID everything works flawlessly for ALL rows!
Stupid error ...