'' (using the single quote character twice) is what you have to use to specify the single quote as an actual character value in the string. Better to just use prepared statement bind items and avoid the problem.
Is there any other way to execute it with Statement because my query is not so long and Statement is enough for it.
[ February 16, 2006: Message edited by: sinasi susam ]
Use PreparedStatement, use PreparedStatement, use PreparedStatement. - It's more secure (Google for "SQL injection attack") - you never have to worry about escape characters for quotes - you reduce the risk of coding an implicit datatype conversion, which is somtehing that is likely to break when the code is ported to another database or database settings are changed - on many databases, it's faster, especially when many queries are running at once
Using Statement when you can use PreparedStatement is almost always a mistake, often a major one. When my company interviews a Java programmer who claims to know JDBC, we gave him a chance to make that mistake; if he does, we often don't hire him.
The "resistence" comments aren't about you, just about something that has become almost a constant theme on this forum. Consider it a "welcome to the family" ribbing.
Two parts to the issue:
- why were both created in the first place - when would you use one versus the other
Historically PS was much slower to create, faster to execute, so you tended to create them more when you would re-use the statement. That really isn't the case any longer. Somebody recently posted some stats here on the forum, you pretty much always win with PS.
The fundamental issue isn't "Statement versus PreparedStatement", it is dynamic SQL versus SQL with bind items. Statement only allows the former. PreparedStatement allows both. Sun isn't going to deprecate Statement because there is too much code out there using it.
So, looking at dynamic SQL versus SQL with bind items, the reasons are many, but at a quick pass:
- you end up creating more hacks to get around parsing and data conversion problems with dynamic SQL - dynamic SQL is much harder for most databases to process, so it is almost always slower - dynamic SQL solutions don't scale as well in some database (like Oracle); they can support more query threads for SQL with bind items than they can for dynamic SQL.
If its complately useless so why Sun is still putting it in JDBC?
Because Sun has never removed a single method call from the Java API. The most that may happen is that they become deprecated - even those methods that are actually broken, not just those that have outlived their usefulness.
Sometimes people build webapps that just shovel form fields blindly into a dynamic SQL string. If a hacker reads the source of your pages they can figure out other combinations to put into a GET or POST in order to extract data that you hadn't intended to extract, or modify data in a way you hadn't intended to modify. If you have form/request validation that blocks these you may be safe, but you have to pay attention to what is possible to do in the request parameters in combination, not just if any one field validates to an expected format (number, date, whatever).
Reid - SCJP2 (April 2002)
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop