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:
None 
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
Description:
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!

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.049 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.