Bug #9320 getMetaData on a prepared INSERT adds null row
Submitted: 21 Mar 2005 20:03 Modified: 24 Mar 2005 18:20
Reporter: Erik Tkal Email Updates:
Status: Closed Impact on me:
Category:Connector / J Severity:S2 (Serious)
Version:3.1.7 OS:Windows (WinXP and Solaris)
Assigned to: Mark Matthews CPU Architecture:Any

[21 Mar 2005 20:03] Erik Tkal
If I create a PreparedStatement from an INSERT SQL statement and then call PreparedStatement.getMetaData() on that I get a valid handle back, which I expect to be a ResultSetMetaData object if the statement were to return one.  However, in addition, a null row is added to the target table. At first our QE folks thought this was because none of the columns in the table were specified as "not null", though a subsequent test showed the null row to be added regardless.

Since I have not executed the statement at all yet I would never expect any updates to the table to be made.

In addition, why do I just not get a null handle back from PreparedStatement.getMetaData() since there will not be a valid result set?  The other JDBC drivers we have tested with return null handles.  Or is there a better way to test whether or not a result set is expected? (We do not parse the SQL statement since it may in fact be a stored procedure - we are DB independent.)

How to repeat:
Create a DB table.
Create a PreparedStatement from a SQL INSERT statement.
Call PreparedStatement.getMetaData() on the resulting handle.
Note inserted row in table.
[21 Mar 2005 20:12] Mark Matthews
If you're not using MySQL-4.1.x or newer, the JDBC driver has to issue a query to get a result set back to get the metadata, as MySQL-4.0 and older don't actually have prepared statements (they're all emulated by the JDBC driver for these older servers).

We need to add a check to perform this for SELECT queries only, and we'll fix this for 3.1.8, which is to be released sometime later this week.

As a workaround, if you _know_ a query won't be a SELECT, you could not call .getMetaData().
[24 Mar 2005 18:20] Mark Matthews
Fixed for 3.1.8. Thanks for your bug report!