Ich hatte ein ähnliches Problem. Ich denke, es ist ein Fehler im Oracle JDBC 7-Treiber (ojdbc7.jar). Der Fehler könnte in der Methode PreparedStatement.getParameterMetaData liegen.
Diese Methode wird intern von Apache DBUtils verwendet. Es wäre also kein Fehler von DBUtils, sondern ein Fehler von Oracle JDBC-Treiber, der mit Oracle 12c verteilt wird.
Dieselbe Abfrage wird wahrscheinlich gut funktionieren, wenn Sie den Treiber Oracle 11g ojdbc6.jar verwenden. Bei mir hat es zumindest funktioniert.
Wenn Sie sehen möchten, wie die Abfrage intern vom Oracle-Treiber ojdbc7.jar falsch verarbeitet wird, können Sie die Hauptmethode verwenden, die in der Klasse oracle.jdbc.driver.OracleParameterMetaDataParser enthalten ist. Versuchen Sie Folgendes:
zB
Die Ausgabe ist Ihr SQL-Satz, der geparst und in eine SQL-Abfrage konvertiert wurde, die intern vom Treiber verwendet wird, um die Parameterdatentypen zu identifizieren:
Aber wie Sie im Beispiel sehen können, wird der FIRSTNAME fälschlicherweise nur als "F" geparst.
Wenn Sie eine der Abfragen verwenden, die Sie in Ihre Frage stellen, ist das Ergebnis, dass einer der Parameter einfach verschwindet ... der Parser sagt also "5" Parameter, aber die interne Abfrage, die zum Abrufen der Datentypen verwendet wird, hat tatsächlich nur "4" (HUMIDITY hat aus dem SELECT gegangen).
Ausgabe:
Wie man es repariert? Keine Ahnung, aber wie ich oben sagte, funktioniert dieselbe Abfrage mit dem Oracle 11g ojdbc6.jar-Treiber (sogar eine Verbindung mit einer Oracle 12c-Datenbank ...).
Das Verhalten ist ziemlich willkürlich. Es sieht so aus, als ob es vom ersten Buchstaben der Spalte abhängt, die im UPDATE verwendet wird. Wenn es mit F und H beginnt, schlägt es immer fehl, aber ich weiß nicht, ob es eine andere Bedingung gibt.
