Bug #5133 preparedStatement.toString() returns an object address for statements
Submitted: 20 Aug 2004 21:12 Modified: 31 Aug 2004 1:20
Reporter: surajz shrestha Email Updates:
Status: Can't repeat Impact on me:
None 
Category:Connector / J Severity:S3 (Non-critical)
Version:3.0.14 OS:Windows (xp)
Assigned to: Mark Matthews CPU Architecture:Any

[20 Aug 2004 21:12] surajz shrestha 
Description:
From 3.0.14 preparedStatement.toString() returns an object address, if string passed to the con.preparedStatement does not have a place holder (?).  I am building query string dynamically, so sometimes I don't need to put ? on my query string. 

In 3.0.11 you could use ps.toString() method to get the string representation of the preparedStatement, even if the originalSql had no place holder. 

How to repeat:
ps = con.prepareStatement("select * from t1");
System.out.println(ps.toString());

Suggested fix:
in
String toString(){
.......
if (parameterValues.length == 0){
   return originalSql;
........
....
}
[31 Aug 2004 1:20] Mark Matthews 
The following testcase does not exhibit the bug, it returns "com.mysql.jdbc.PreparedStatement@f0eed6: SELECT 1".

public void testBug5133() throws Exception {
    	String query = "SELECT 1";
    	String output = this.conn.prepareStatement(query).toString();
    	System.out.println(output);
    	
    	assertTrue(output.indexOf(query) != -1);	
    }
[9 Mar 2008 0:39] Giw Aalam 
@Mark Matthews

Your workaround does not provide a solution for queries containing questionmarks. So annoyingly this doesn't help in most cases using a PreparedStatement. 

e.g. "INSERT INTO abcd VALUES (?, ?, ?)";

Neither the "toString()" function nor your workaround can provide me a string containing the real values of each questionmark. That's the core problem.

best regard, 
Giw
[9 Mar 2008 0:50] Mark Matthews 
Our implementation certainly does provide you the bound parameters in the output of PreparedStatement.toString(), if they're there. We use it all the time in logging, and in debugging sessions.

Are you sure you're not using a connection pool? If so, they *wrap* our prepared statement, and there's no requirement that *their* implementation of .toString() does anything in particular, including calling that of the wrapped PreparedStatement instance.