Mark
> Ledion,
>
> I'm not sure I've ever seen the JDBC spec state
> "matched vs. affected". The APIDOCS for
> java.sql.Statement.executeUpdate() state
I was using the _mysql_ terms for matched (ie satisfy the where clause) and updated.
> "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).
Well, I don't think that conforms with the JDBC specifications from SUN, that you can find here
http://java.sun.com/products/jdbc/download.html#corespec30
Check out 13.1.2 here they use update count (which I think is number of rows that were updated), but the next one makes it clearer.
Check out 13.2.4.2, it talks about prepared statements, but I think it is clear that executeUpdate needs to return the number of affected rows (updated rows)
> -Mark
>
Ledion