Ledion B wrote:
> Hi,
>
> According to the JDBC specifications the
> executeUpdate(String query), should return the
> number of values affected (NOT the number of rows
> that matched)
>
> I am using executeUpdate to do some record locking
> and it turns out that executeUpdate returns the
> number of rows matched. Here is what I am using
>
> 1. mysql4.1.10-nt
> 2. mysql-connector-java-3.1.7-bin.jar
> 3. OS windows XP
>
> and I issue a simple
> executeUpdate("UPDATE records set locked=1 where
> id = 1);
>
> no matter what the locked value is prior to
> issuing this query the returned value is 1.
>
> Can anyone confirm this? Or do you think of
> anything I am doing wrong.
>
> Ledion
Ledion,
I'm not sure I've ever seen the JDBC spec state "matched vs. affected". The APIDOCS for java.sql.Statement.executeUpdate() state
"either the row count for INSERT, UPDATE or DELETE statements, or 0 for SQL statements that return nothing"
MySQL is the only database _I_ know of that has a concept of affected vs. matched rows for . The JDBC driver tells the server to return _matched_, as it's conceptually what all other databases return, as the fact that the database skipped doing the update because the row already matched the UPDATE condition is an _optimization_.
Since JDBC is a cross-vendor API, we need to use the same semantics as other vendors and the SQL specification, which is to return the number of rows that met the update _condition_, not the number of rows that were updated minus the ones that already had the required values (the optimization).
-Mark
Mark Matthews
Consulting Member Technical Staff - MySQL Enterprise Tools
Oracle
http://www.mysql.com/products/enterprise/monitor.html