BackGroud Story:

I have observed that Sybase JDBC driver (jconn3) is eating exceptions on Statement.ExecuteUpdate(sql).
The SQL statement was an Insert statement which inserts a row into a table (This is not a temp table) but still Statement.ExecuteUpdate(sql) returns 0 dues to unknown reasons. This issue is random and do no appear to happen everytime.

My understanding is Statement.ExecuteUpdate(sql) returns 0 if no rows have been updated. But as the case is of Insert statement I am not sure why exception was not thrown if nothing was inserted.
As the code is legacy (JDK 1.4 is being used) and due to some limitation I am not able to change or update JDBC Driver.


Possiblilties :

I was thinking with an angle if Driver has different internal implementation of ExecuteUpdate with respect to Statement,PreparedStatement and CallableStatement then I can suggest to change Statement to CallableStatement to call ExecuteUpdate.

I am curious to know if the implementation of ExecuteUpdate is possibly different for Statement,PreparedStatement and CallableStatement in Sybase JDBC Driver.

1

There are 1 answers

2
Gord Thompson On BEST ANSWER

I am curious to know if the implementation of ExecuteUpdate is possibly different for Statement,PreparedStatement and CallableStatement in Sybase JDBC Driver.

The implementation of .executeUpdate will be different for Statement and PreparedStatement objects in any JDBC driver because the two objects work differently.

A Statement object is just an object to execute an arbitrary SQL statement. The SQL statement is not supplied when you create the object using Connection#createStatement, it is passed as an argument to the Statement#executeUpdate method.

Creating a PreparedStatement object requires that we supply the SQL statement when we call the Connection#prepareStatement method. The SQL statement is "pre-compiled" and cached as part of the object. When the time comes to execute the statement we only need to call the PreparedStatement#executeUpdate method (with no arguments) because the SQL code has already been "prepared".

Since Statement#executeUpdate must be given an argument and PreparedStatement#executeUpdate must not be given an argument they clearly must be implemented somewhat differently.