阿帕奇Dbutils在UPDATE SQL更改列名 [英] Apache Dbutils changing column name in update Sql

查看:495
本文介绍了阿帕奇Dbutils在UPDATE SQL更改列名的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有Dbutils一个奇怪的问题,我试图运行参数化的更新SQL,我提供的参数正确的号码,但dbutils通过改变修改的名字修改时间戳列命名为

I am having a strange problem with Dbutils , I am trying to run a parameterized update sql, I am supplying correct number of arguments , but dbutils is modifying the timestamp column name by changing the name of modifying it

在时间戳COLUMNNAME一个字母

when timestamp columnname is one alphabet

java.sql.SQLException中:参数错误号:预计4,是
  给予5查询:UPDATE WEATHER_2 SET天气预报=? ,
  O = TO_TIMESTAMP(,'YYYY-MM-DD HH24:MI:SS.FF'?),湿度=? ,TEMP =?
  WHERE ID =?参数:[804,2015年6月5日17:21:05.809,16.0,25.15,
  1347927】

java.sql.SQLException: Wrong number of parameters: expected 4, was given 5 Query: UPDATE WEATHER_2 SET WEATHER=? , O=TO_TIMESTAMP(?,'YYYY-MM-DD HH24:MI:SS.FF') , HUMIDITY=? , TEMP=? WHERE ID=? Parameters: [804, 2015-06-05 17:21:05.809, 16.0, 25.15, 1347927]

在时间戳COLUMNNAME是normal..it将ommit第二个字母

when timestamp columnname is normal..it will ommit the second alphabet

值java.sql.SQLException:ORA-00904:OSTIME:无效的标识符
       查询:UPDATE WEATHER_2 SET天气预报=? ,OBSTIME = TO_TIMESTAMP(,'YYYY-MM-DD HH24:MI:SS.FF'?),湿度=? ,
  TEMP =? WHERE ID =?参数:[804,2015年6月5日17:27:46.139,16.0,
  25.15,1347927]

java.sql.SQLException: ORA-00904: "OSTIME": invalid identifier Query: UPDATE WEATHER_2 SET WEATHER=? , OBSTIME=TO_TIMESTAMP(?,'YYYY-MM-DD HH24:MI:SS.FF') , HUMIDITY=? , TEMP=? WHERE ID=? Parameters: [804, 2015-06-05 17:27:46.139, 16.0, 25.15, 1347927]

这会是一个数据库的事情吗?此外,它只能在其类型为日期或时间戳列发生。

could this be a database thing? Also this is only happening with column whose type is Date or Timestamp.

推荐答案

我有一个类似的问题。我认为这是在Oracle JDBC 7驱动程序(ojdbc7.jar)的错误。该错误可能是在preparedStatement.getParameterMetaData方法。

I had a similar issue. I think it is a bug in the Oracle JDBC 7 Driver (ojdbc7.jar). The bug could be in the PreparedStatement.getParameterMetaData method.

此方法是由Apache DBUtils内部使用。所以它不会是DBUtils的一个bug,但Oracle JDBC驱动程序与Oracle 12c中分布的错误。

This method is used internally by the Apache DBUtils. So it would not be a bug of DBUtils, but a bug from Oracle JDBC driver distributed with Oracle 12c.

如果您使用的Oracle 11g ojdbc6.jar驱动器相同的查询可能会正常工作。它至少为我工作。

Same Query will probably work fine if you use the Oracle 11g ojdbc6.jar driver. It at least worked for me.

如果您想了解查询被错误由Oracle ojdbc7.jar驱动程序内部处理,可以使用包含在oracle.jdbc.driver.OracleParameterMetaDataParser类的主要方法。试试这个:

If you want to see how the Query is wrongly processed internally by the Oracle ojdbc7.jar driver, you can use the main method included in the oracle.jdbc.driver.OracleParameterMetaDataParser class. Try this:

Java的-classpath ojdbc7.jar
  oracle.jdbc.driver.OracleParameterMetaDataParser您的SQL HERE

java -classpath ojdbc7.jar oracle.jdbc.driver.OracleParameterMetaDataParser "YOUR SQL HERE"

例如

Java的-classpath ojdbc7.jar
  oracle.jdbc.driver.OracleParameterMetaDataParser更新人SET
  LASTNAME = ?, FIRSTNAME =? WHERE PERSONID =?

java -classpath ojdbc7.jar oracle.jdbc.driver.OracleParameterMetaDataParser "UPDATE PERSON SET LASTNAME=?, FIRSTNAME=? WHERE PERSONID=?"

输出你的SQL语句解析并转换为内部使用由驱动程序来确定参数的数据类型的SQL查询:

The output is your SQL Sentence parsed and converted to a SQL Query that is used internally by the driver to identify the parameter datatypes:

SQL:更新人SET LASTNAME =:1,名字= 2 WHERE PERSONID =:3
  SqlKind:UPDATE,参数个数= 3参数SQL:SELECT LASTNAME,女,
  PERSONID由人

SQL:UPDATE PERSON SET LASTNAME=:1 , FIRSTNAME=:2 WHERE PERSONID=:3 SqlKind:UPDATE, Parameter Count=3 Parameter SQL: SELECT LASTNAME, F, PERSONID FROM PERSON

但你可以在样品中看到的,将名字被错误解析,就像F。

But as you can see in the sample, the FIRSTNAME is wrongly parsed just as "F".

使用你把你的问题的一个查询,结果是其中一个参数只是消失...所以解析器说,5PARAMS,但用于获取数据类型的内部查询方面确实只有4 (湿度已经从SELECT消失)。

Using one of the Queries you put in your question, the result is that one of the parameters just disappear... so the parser says "5" params but the internal Query used to get the datatypes has indeed only "4" (HUMIDITY has gone from the SELECT).

Java的-classpath ojdbc7.jar
  oracle.jdbc.driver.OracleParameterMetaDataParserUPDATE WEATHER_2 SET天气预报=,= OBSTIME TO_TIMESTAMP?('YYYY-MM-DD HH24:MI:SS.FF'?)???,湿度=,TEMP = WHERE ID =

java -classpath ojdbc7.jar oracle.jdbc.driver.OracleParameterMetaDataParser "UPDATE WEATHER_2 SET WEATHER=? , OBSTIME=TO_TIMESTAMP(?,'YYYY-MM-DD HH24:MI:SS.FF') , HUMIDITY=? , TEMP=? WHERE ID=?"

输出:

SQL:UPDATE WEATHER_2 SET天气预报= 1,OBSTIME = TO_TIMESTAMP(:2
  ,'YYYY-MM-DD HH24:MI:SS.FF'),湿度= 3,TEMP = 4 WHERE ID = 5结果
  SqlKind:UPDATE,参数个数= 5结果
  参数SQL:选择天气,OBSTIME,TEMP,ID FROM WEATHER_2

SQL:UPDATE WEATHER_2 SET WEATHER=:1 , OBSTIME=TO_TIMESTAMP(:2 ,'YYYY-MM-DD HH24:MI:SS.FF') , HUMIDITY=:3 , TEMP=:4 WHERE ID=:5
SqlKind:UPDATE, Parameter Count=5
Parameter SQL: SELECT WEATHER, OBSTIME, TEMP, ID FROM WEATHER_2

如何fixit来?不知道,但正如我上面所说的,使用的Oracle 11g ojdbc6.jar驱动程序,同样的查询工作(甚至与Oracle数据库12C连接...)。

How to fixit? No idea, but as I said above, using the Oracle 11g ojdbc6.jar driver, same query works (even connecting with an Oracle 12c database...).

该行为是pretty随机的。它看起来像它取决于在UPDATE使用的列的第一个字母。如果开始F和H总是失败,但我不知道是否有任何其他条件。

The behaviour is pretty random. It looks like it depends on the first letter of the column used in the UPDATE. If it begins with F and H always fails, but I do not know if there is any other condition.

这篇关于阿帕奇Dbutils在UPDATE SQL更改列名的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆