Issue with the getUpdateCount() in UltraliteJ

[former_SQLA_member1694873]

There seems to be an issue when calling the PreparedStatement.getUpdateCount() in conjunction with calling the Connection.getLastIdentity() method in UltraliteJ. You get different results depending on in which order you call them.

To illustrate using the CustDB app distributed with SA17,

• change the cust_id column to DEFAULT AUTOINCREMENT
• then execute the following code

ps.execute("INSERT INTO ULCustomer (cust_name) VALUES('joe')");
Log.d(this.getClass().getName(), "getUpdateCount() = " + ps.getUpdateCount());
Log.d(this.getClass().getName(), "getLastIdentity() = " + _conn.getLastIdentity());

you get the expected output,

getUpdateCount() = 1
getLastIdentity() = 1

• however if you reverse the calls to GetUpdateCount() and getLastIdentity() as follows,

ps.execute("INSERT INTO ULCustomer (cust_name) VALUES('joe')");
Log.d(this.getClass().getName(), "getLastIdentity() = " + _conn.getLastIdentity());
Log.d(this.getClass().getName(), "getUpdateCount() = " + ps.getUpdateCount());

you get the output,

getLastIdentity() = 1
getUpdateCount() = -1

Note the value of -1. It looks like the call to getLastIdentity() somehow destroyed the value for getUpdateCount().

Obviously I can work around this, but I think it's a bug.

Terry

[former_SQLA_member1694876 · Accepted solution]

Hi Terry,

Here's what's likely happening: the modified rows count is stored by the underlying UltraLite runtime in a per-request data structure, along with the error information. The call to get the last identity is a separate request, and that clears the data structure. The -1 value indicates the last request wasn't one that affects rows.

This means that if you get the update count immediately following the execute, things will be good (as you've discovered). And perhaps we should also look at improving this so it doesn't look like a bug. 🙂

[former_SQLA_member1694873 · Accepted solution]

I figured it was something like that. It also shows up if I call ps.hasResultSet() before calling getUpdateCount(). The current behaviour does seem counter-intuitive - I would expect those values to persist until the next execution request 🙂

Thanks.