J'ai eu un problème similaire. Je pense que c'est un bogue dans le pilote Oracle JDBC 7 (ojdbc7.jar). Le bogue pourrait être dans la méthode PreparedStatement.getParameterMetaData.
Cette méthode est utilisée en interne par Apache DBUtils. Il ne s'agirait donc pas d'un bogue de DBUtils, mais d'un bogue du pilote Oracle JDBC distribué avec Oracle 12c.
La même requête fonctionnera probablement correctement si vous utilisez le pilote Oracle 11g ojdbc6.jar. Cela a au moins fonctionné pour moi.
Si vous souhaitez voir comment la requête est traitée à tort en interne par le pilote Oracle ojdbc7.jar, vous pouvez utiliser la méthode principale incluse dans la classe oracle.jdbc.driver.OracleParameterMetaDataParser. Essayez ceci :
ex.
La sortie est votre phrase SQL analysée et convertie en une requête SQL utilisée en interne par le pilote pour identifier les types de données des paramètres :
Mais comme vous pouvez le voir dans l'exemple, le FIRSTNAME est analysé à tort comme "F".
En utilisant l'une des requêtes que vous avez posées dans votre question, le résultat est que l'un des paramètres disparaît simplement ... donc l'analyseur dit "5" paramètres mais la requête interne utilisée pour obtenir les types de données n'a en effet que "4" (HUMIDITY a disparu du SELECT).
sortie :
Comment le réparer? Aucune idée, mais comme je l'ai dit plus haut, en utilisant le pilote Oracle 11g ojdbc6.jar, la même requête fonctionne (même en se connectant à une base de données Oracle 12c...).
Le comportement est assez aléatoire. Il semble que cela dépende de la première lettre de la colonne utilisée dans UPDATE. S'il commence par F et H échoue toujours, mais je ne sais pas s'il existe une autre condition.
