UCanAccess is simply passing along the value returned by HSQLDB when it calls executeUpdate on a CallableStatement and that appears to always be zero as illustrated by the test code ...
packagecom.example.hsqldbtest;importjava.sql.*;publicclassHsqldbTestMain{publicstaticvoidmain(String[]args){StringconnectionUrl="jdbc:hsqldb:mem:memdb";try(Connectionconn=DriverManager.getConnection(connectionUrl,"SA","")){try(Statements=conn.createStatement()){s.execute("CREATE TABLE table1 (id INT PRIMARY KEY, qty INT)");s.execute("INSERT INTO table1 (id, qty) VALUES (1, 10)");s.execute("INSERT INTO table1 (id, qty) VALUES (2, 20)");s.execute("CREATE PROCEDURE bump_qty() "+"MODIFIES SQL DATA "+"BEGIN ATOMIC "+"UPDATE table1 SET qty = qty + 1 WHERE id = 1; "+"END");}dumpTable(conn);try(CallableStatementcs=conn.prepareCall("{call bump_qty()}")){inti=cs.executeUpdate();System.out.printf("%nHSQLDB CallableStatement#executeUpdate returned %d%n%n",i);}dumpTable(conn);}catch(Exceptione){e.printStackTrace(System.err);}}privatestaticvoiddumpTable(Connectionconn)throwsSQLException{try(Statements=conn.createStatement();ResultSetrs=s.executeQuery("SELECT id, qty FROM table1 ORDER BY id")){while(rs.next()){System.out.printf("id: %d, qty: %d%n",rs.getInt(1),rs.getInt(2));}}}}
That's understandable from HSQLDB's perspective because a stored procedure could conceivably contain many DML statements that could affect many different tables, and a single "row(s) affected" value would not be terribly meaningful.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hey guys,
is the returned value from this method currently not implemented or am i doing something wrong?
despite the called statement actually affecting rows in the db file, it keeps returning 0 instead of true row count.
thanks!
Hi Igal. No, you aren't missing anything.
UCanAccess is simply passing along the value returned by HSQLDB when it calls
executeUpdate
on aCallableStatement
and that appears to always be zero as illustrated by the test code ...which produces
That's understandable from HSQLDB's perspective because a stored procedure could conceivably contain many DML statements that could affect many different tables, and a single "row(s) affected" value would not be terribly meaningful.