Miałem podobny problem. Myślę, że jest to błąd w sterowniku Oracle JDBC 7 (ojdbc7.jar). Błąd może być w metodzie PreparedStatement.getParameterMetaData.
Ta metoda jest używana wewnętrznie przez Apache DBUtils. Nie byłby to więc błąd DBUtils, ale błąd sterownika Oracle JDBC dystrybuowanego z Oracle 12c.
To samo zapytanie prawdopodobnie zadziała poprawnie, jeśli użyjesz sterownika Oracle 11g ojdbc6.jar. U mnie to przynajmniej zadziałało.
Jeśli chcesz zobaczyć, jak Query jest błędnie przetwarzane wewnętrznie przez sterownik Oracle ojdbc7.jar, możesz użyć metody main zawartej w klasie oracle.jdbc.driver.OracleParameterMetaDataParser. Spróbuj tego:
np.
Wynikiem jest przeanalizowanie zdania SQL i przekonwertowanie go na zapytanie SQL, które jest używane wewnętrznie przez sterownik do identyfikacji typów danych parametrów:
Ale jak widać w przykładzie, FIRSTNAME jest błędnie analizowane jako „F”.
Używając jednego z zapytań, które umieściłeś w swoim pytaniu, wynik jest taki, że jeden z parametrów po prostu znika... więc parser mówi "5" parametrów, ale wewnętrzne zapytanie użyte do uzyskania typów danych ma rzeczywiście tylko "4" (WILGOTNOŚĆ ma zniknął z SELECT).
wyjście:
Jak to naprawić? Nie mam pojęcia, ale jak powiedziałem powyżej, używając sterownika Oracle 11g ojdbc6.jar, to samo zapytanie działa (nawet łącząc się z bazą danych Oracle 12c...).
Zachowanie jest dość przypadkowe. Wygląda na to, że zależy to od pierwszej litery kolumny użytej w UPDATE. Jeśli zaczyna się od F i H, zawsze kończy się niepowodzeniem, ale nie wiem, czy jest jakiś inny warunek.
