Ik had een soortgelijk probleem. Ik denk dat het een bug is in de Oracle JDBC 7 Driver (ojdbc7.jar). De fout kan in de methode PreparedStatement.getParameterMetaData zitten.
Deze methode wordt intern gebruikt door de Apache DBUtils. Het zou dus geen bug van DBUtils zijn, maar een bug van het Oracle JDBC-stuurprogramma dat wordt gedistribueerd met Oracle 12c.
Dezelfde query zal waarschijnlijk goed werken als u het Oracle 11g ojdbc6.jar-stuurprogramma gebruikt. Het werkte in ieder geval voor mij.
Als u wilt zien hoe de query intern verkeerd wordt verwerkt door het stuurprogramma Oracle ojdbc7.jar, kunt u de hoofdmethode gebruiken die is opgenomen in de klasse oracle.jdbc.driver.OracleParameterMetaDataParser. Probeer dit:
bijv.
De uitvoer is uw SQL-zin, geparseerd en geconverteerd naar een SQL-query die intern door het stuurprogramma wordt gebruikt om de parametergegevenstypen te identificeren:
Maar zoals u in het voorbeeld kunt zien, wordt de FIRSTNAME verkeerd geparseerd, net als "F".
Als u een van de query's gebruikt die u in uw vraag hebt gesteld, is het resultaat dat een van de parameters gewoon verdwijnt ... dus de parser zegt "5" params, maar de interne query die wordt gebruikt om de datatypes te krijgen, heeft inderdaad slechts "4" (VOCHTIGHEID heeft verdwenen uit de SELECT).
uitgang:
Hoe repareer je het? Geen idee, maar zoals ik hierboven al zei, met het Oracle 11g ojdbc6.jar-stuurprogramma, werkt dezelfde query (zelfs verbinding maken met een Oracle 12c-database...).
Het gedrag is vrij willekeurig. Het lijkt erop dat het afhangt van de eerste letter van de kolom die in de UPDATE wordt gebruikt. Als het begint met F en H faalt altijd, maar ik weet niet of er een andere voorwaarde is.