Andrus Adamchik wrote:
> No, you can do it in the batch:
>
> http://java.sun.com/j2se/1.4.1/docs/api/java/sql/
> Statement.html#executeBatch()
>
> executeBatch returns an int[] that can be analyzed.
Nice try, but with Oracle the world is not what it seems :-)
Decompiling the oracle driver shows what you get:
public int[] executeBatch() throws SQLException {
.....
for(int k = 0; k < ai2.length; k++) ai2[k] = -2;
int ai1[] = ai2;
return ai1;
}
}
}
This is the same "-2" you see in the log if you run the context-commit
on DEBUG level.
You should note the fully useless assigment in the line before
the return - this is an indication on what level of java developers
wrote this spaghetti.
So no more surprises if you try the alternative
PreparedStatement.getUpdateCount() method,
which works sometimes, but not with my prepared
statement cache:
public synchronized int getUpdateCount()
throws SQLException
{
connection.trace("Statement.getUpdateCount");
if(noMoreUpdateCounts)
return -1;
noMoreUpdateCounts = true;
DBAccess _tmp = connection.db_access;
if(sql_kind == 3)
return 0;
DBAccess _tmp1 = connection.db_access;
if(sql_kind != 2)
return -1;
else
return dbstmt.rows_processed;
}
The guy was clever enough to reset
the "noMoreUpdateCounts" variable
in *almost* any execute method
- except for the executeBatch....
This driver is is a peace of shit,
so I think Holger should be rather
happy that IBM obfuscated their
driver - because nobody likes
to see that :-)
Anyhow, I did a real bad hack
in my prepared statement cache
to make getUpdateCount work,
but I think for the individual
update counts there's no chance
for oracle.
regards,
Arndt
This archive was generated by hypermail 2.0.0 : Sat May 24 2003 - 16:15:05 EDT