posted 22 years ago
Yeah, looks like you're right. Therefore, I took matters into my own hands and created my own class named DynamicStatement. It's very similar to PreparedStatement in that you have access to most of the frequently used set<type>() methods, such as setInt(), setString(), and setDate().
My class also gives the user the ability to append to the statement. So if the user wanted to add a NOT IN clause, or an AND conditional, no problem.
The internal query is managed by a StringBuffer, so it's easy to replace all the "?" with most data types you provide. Of course I didn't get complicated and provide methods like setBlob() and setAsciiStream(), but hell, I've never used those methods, so no need to add crap I wont be using.
The date formatting I used for setDate() is specific to Oracle, but I guess I can implement a way to make it flexible to work with any database.
Also, the set() methods I created dont require an index argument like they do in PreparedStatement. Just call setString("bite me") instead of PreparedStatement.setString( 1, "bite me"). Of course you must ensure that you call the set methods in the order that the parameters are expecting the correct data in your sql statement, but that's no problem since most people use PreparedStatement the same way.
I wrote this class really quick. I'm sure there are things I overlooked, but I tested it out and it works nice. Tell me what you think.
[This message has been edited by SAFROLE YUTANI (edited November 30, 2001).]