Java.sql.Statement in the API of JDBC (Java Database Connectivity, Java Database Connection) requires developers to pay a lot of time and effort. One common problem with the use of the Statement Get JDBC access is to enter the date and timestamp of the appropriate format: 2002-02-05 20:56 or 02/05/02 8:56 PM.
By using java.sql.preparedStatement, this problem can be saved automatically. A preparedStatement is obtained from the java.sql.connection object and the supplied SQL string, and the SQL string contains the question mark (?), These question marks indicate the position of the variable, then provide the value of the variable, finally executing the statement, for example:
Stringsql = "SELECT *WHERE P.ID =? and p.Name =?"; preparedStatement PS = Connection.PrepareStatement (SQL); ps.setint (1, ID); ps.setstring (2, name); ResultSet RS = ps.executeQuery (); Another advantage of using PreparedStatement is that the string is not dynamically created. Below is an example of a dynamically created string:
Stringsql = "Select * from people p where p.i =" ID;
This allows JVM (JavaVirtual Machine, Java virtual machine), and driver / database bundle statements and strings and improve performance.
PreparedStatement also provides a database independent. The fewer SQL displayed, the smaller the database dependence of the potential SQL statement.
Since PreparedStatement has a lot of advantages, developers may usually use it, only the usual Statement is used when it is because of performance reasons or in a row of SQL statements.
An example of a complete preparedStatement:
Package JSTARPROJECT; Import Java.sql. *;
Public class mypreparedStatement {
Private final string db_driver = "com.microsoft.jdbc.sqlserver.sqlserverdriver"; private final string url = "JDBC: Microsoft: SQLServer: //127.0.0.1: 1433; DatabaseName = PUBS"
public mypreparedstatement () {} public void query () throws sqlexception {connection conn = this.getconnection (); string strsql = "select emp_id from employee where emp_id =?"; preparedstatement pstmt = conn.preparestatement (strsql); pstmt.setstring (1, "PMA42628M"); ResultSet RS = pstmt.executeQuery ();
While (rs.next ()) {string fname = rs.getstring ("EMP_ID"); System.Out.println ("The FName IS";}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} rs.close (); pstmt.close (); conn .Close ();
} Private connection getconnection () throws sqlexception {// class connection conn = null;. Try {class.forname (db_driver); conn = drivermanager.getconnection (url, "sa", "sa");} catch (classnotfoundexception ex) {} return conn;} // main public static void main (string [] args) throws sqlexception {mypreparedstatement jdbctest1 = new mypreparedstatement (); jdbctest1.query ();}} Why should we always use PreparedStatement instead of Statement Why do you always use? PreparedStatement replaces Statement? In JDBC applications, if you are already a slightly horizontal developer, you should always replace Statement at preparedStatement. That is, don't use Statement at any time. Based on the following reason: one. Code Readiness and maintainability. Although using preparedStatement instead of Statement will make the code a few lines, the code is much higher than the readability or maintenanceability of the STATEMENT: STMT. ExecuteUpdate ("INSERT INTO TB_NAME (COL1, COL2, COL2, COL4) VALUES ('" var1 ",'" var2 "," var 4 "" "" var 4 ")"); PerstMT = Con. PrepareStatement ("INSERT INTO TB_NAME (COL4) VALUES (?,?,?,?)"; PerstMt.SetString (1, var1); PerstMt.SetString (2, var2); PerstMt.SetString 3, VAR3); PerstMt.SetString (4, var 4); Perstmt .ExecuteUpdate (); don't need me to say, for the first method. Don't say that other people go to your code, that is, you will read it for a while, you will feel sad. II.preparedStatement does the utmost possible to improve performance. A database will do our utmost to provide maximum performance optimization for the pre-compilation statement. Because the pre-encoding statement is possible to be repeated. So the statement is buffered by the execution code compiled by the DB compiler, then as long as the next call Is the same pre-compilation statement does not need to be compiled, as long as the parameters are directly incoming the compiled statement (equivalent to a mandade) will be executed. This is not to say that only a multi-execution translation in the Connection The statement is cached, but for the entire DB, as long as the pre-compiled statement syntax and cache match. So you can do it directly without compilation again at any time. And in the statement, even the same operation, Since the data each operation is different, the opportunity to match the entire statement is minimally matched. For example: INSERT INTO TB_NAME (COL1, COL2) VALUES ('11', '22'); INSERT INTO TB_NAME (col1 , col2) VALUES ('11', '23');
