1

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.

TonyStark
  • 65
  • 7
  • 2
    `.executeUpdate(sql)` does not apply to `PreparedStatement` objects; they need `.executeUpdate()` since the SQL command text is supplied as part of the `.prepareStatement` call. – Gord Thompson Aug 18 '15 at 17:29
  • Is it possible to elaborate a little more ? – TonyStark Aug 19 '15 at 03:11
  • Also its just a blind try to use PreparedStatement / CallabableStatement in place of Statement. So was curious if it can be really justified. – TonyStark Aug 19 '15 at 03:13
  • Calling `executeUpdate(String)` (or any other execute method taking a string parameter) on a `PreparedStatement` or `CallableStatement` must throw an SQLException, it is required by the JDBC specification. – Mark Rotteveel Aug 19 '15 at 06:54
  • @MarkRotteveel you may be right. But the driver is eating up the exceptions for sure instead of throwing it up. There must be some sort of scenario where this sort of thing happens. Can you pl tell me if the implementation inside driver JAR for `PreparedStatement` and `CallableStatement` will be different by any chance ? – TonyStark Aug 21 '15 at 11:58
  • @TonyAdityaStark I don't understand your question. However, each JDBC driver needs to provide its own implementation. JDBC itself is only a collection of interfaces (+ a small number of supporting classes). So if the driver is "eating" the exception, that is a bug in the driver. – Mark Rotteveel Aug 21 '15 at 12:28
  • @Gord Thompson: Could you please elaborate a little more? – TonyStark Aug 24 '15 at 01:57

1 Answers1

2

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.

Gord Thompson
  • 116,920
  • 32
  • 215
  • 418
  • Thanks for the explanation. This is something I was looking for. Please correct me if my understanding is wrong, I think implementation of `executeUpdate` will be also different for `CallableStatement`, right ? – TonyStark Aug 24 '15 at 13:51
  • 1
    The implementation of `CallableStatement#executeUpdate` *might* be different from the corresponding implementations for `Statement` and `PreparedStatement`. As Mark mentions in his comment to your question, it all depends on how the JDBC driver was written. – Gord Thompson Aug 24 '15 at 14:01