Friday, 16 August 2013

JDBC - Statement Object Example

Following is the example which makes use of following three queries along with opening and closing statment:
  • boolean execute(String SQL) : Returns a boolean value of true if a ResultSet object can be retrieved; otherwise, it returns false. Use this method to execute SQL DDL statements or when you need to use truly dynamic SQL.
  • int executeUpdate(String SQL) : Returns the numbers of rows affected by the execution of the SQL statement. Use this method to execute SQL statements for which you expect to get a number of rows affected - for example, an INSERT, UPDATE, or DELETE statement.
  • ResultSet executeQuery(String SQL) : Returns a ResultSet object. Use this method when you expect to get a result set, as you would with a SELECT statement.
This sample code has been written based on the environment and database setup done in previous chapters.
Copy and past following example in JDBCExample.java, compile and run as follows:
//STEP 1. Import required packages
import java.sql.*;

public class JDBCExample {
// JDBC driver name and database URL
static final String JDBC_DRIVER = "com.mysql.jdbc.Driver";
static final String DB_URL = "jdbc:mysql://localhost/EMP";

// Database credentials
static final String USER = "username";
static final String PASS = "password";

public static void main(String[] args) {
Connection conn = null;
Statement stmt = null;
try{
//STEP 2: Register JDBC driver
Class.forName("com.mysql.jdbc.Driver");

//STEP 3: Open a connection
System.out.println("Connecting to database...");
conn
= DriverManager.getConnection(DB_URL,USER,PASS);

//STEP 4: Execute a query
System.out.println("Creating statement...");
stmt
= conn.createStatement();
String sql = "UPDATE Employees set age=30 WHERE id=103";

// Let us check if it returns a true Result Set or not.
Boolean ret = stmt.execute(sql);
System.out.println("Return value is : " + ret.toString() );

// Let us update age of the record with ID = 103;
int rows = stmt.executeUpdate(sql);
System.out.println("Rows impacted : " + rows );

// Let us select all the records and display them.
sql
= "SELECT id, first, last, age FROM Employees";
ResultSet rs = stmt.executeQuery(sql);

//STEP 5: Extract data from result set
while(rs.next()){
//Retrieve by column name
int id = rs.getInt("id");
int age = rs.getInt("age");
String first = rs.getString("first");
String last = rs.getString("last");

//Display values
System.out.print("ID: " + id);
System.out.print(", Age: " + age);
System.out.print(", First: " + first);
System.out.println(", Last: " + last);
}
//STEP 6: Clean-up environment
rs
.close();
stmt
.close();
conn
.close();
}catch(SQLException se){
//Handle errors for JDBC
se
.printStackTrace();
}catch(Exception e){
//Handle errors for Class.forName
e
.printStackTrace();
}finally{
//finally block used to close resources
try{
if(stmt!=null)
stmt
.close();
}catch(SQLException se2){
}// nothing we can do
try{
if(conn!=null)
conn
.close();
}catch(SQLException se){
se
.printStackTrace();
}//end finally try
}//end try
System.out.println("Goodbye!");
}//end main
}//end JDBCExample
Now let us compile above example as follows:
C:\>javac JDBCExample.java
C
:\>
When you run JDBCExample, it produces following result:
C:\>java JDBCExample
Connecting to database...
Creating statement...
Return value is : false
Rows impacted : 1
ID
: 100, Age: 18, First: Zara, Last: Ali
ID
: 101, Age: 25, First: Mahnaz, Last: Fatma
ID
: 102, Age: 30, First: Zaid, Last: Khan
ID
: 103, Age: 30, First: Sumit, Last: Mittal
Goodbye!
C
:\>

JDBC - Statements, PreparedStatement and CallableStatement

Once a connection is obtained we can interact with the database. The JDBC Statement, CallableStatement, and PreparedStatement interfaces define the methods and properties that enable you to send SQL or PL/SQL commands and receive data from your database.
They also define methods that help bridge data type differences between Java and SQL data types used in a database.
Following table provides a summary of each interface's purpose to understand how do you decide which interface to use?

InterfacesRecommended Use
StatementUse for general-purpose access to your database. Useful when you are using static SQL statements at runtime. The Statement interface cannot accept parameters.
PreparedStatementUse when you plan to use the SQL statements many times. The PreparedStatement interface accepts input parameters at runtime.
CallableStatementUse when you want to access database stored procedures. The CallableStatement interface can also accept runtime input parameters.

The Statement Objects:

Creating Statement Object:

Before you can use a Statement object to execute a SQL statement, you need to create one using the Connection object's createStatement( ) method, as in the following example:
Statement stmt = null;
try {
stmt
= conn.createStatement( );
. . .
}
catch (SQLException e) {
. . .
}
finally {
. . .
}
Once you've created a Statement object, you can then use it to execute a SQL statement with one of its three execute methods.
  • boolean execute(String SQL) : Returns a boolean value of true if a ResultSet object can be retrieved; otherwise, it returns false. Use this method to execute SQL DDL statements or when you need to use truly dynamic SQL.
  • int executeUpdate(String SQL) : Returns the numbers of rows affected by the execution of the SQL statement. Use this method to execute SQL statements for which you expect to get a number of rows affected - for example, an INSERT, UPDATE, or DELETE statement.
  • ResultSet executeQuery(String SQL) : Returns a ResultSet object. Use this method when you expect to get a result set, as you would with a SELECT statement.

Closing Statement Object:

Just as you close a Connection object to save database resources, for the same reason you should also close the Statement object.
A simple call to the close() method will do the job. If you close the Connection object first it will close the Statement object as well. However, you should always explicitly close the Statement object to ensure proper cleanup.
Statement stmt = null;
try {
stmt
= conn.createStatement( );
. . .
}
catch (SQLException e) {
. . .
}
finally {
stmt
.close();
}

Refer Statement Example


The PreparedStatement Objects:



The PreparedStatement interface extends the Statement interface which gives you added functionality with a couple of advantages over a generic Statement object.


This statement gives you the flexibility of supplying arguments dynamically.


Creating PreparedStatement Object:


PreparedStatement pstmt = null;
try {
String SQL = "Update Employees SET age = ? WHERE id = ?";
pstmt
= conn.prepareStatement(SQL);
. . .
}
catch (SQLException e) {
. . .
}
finally {
. . .
}
All parameters in JDBC are represented by the ? symbol, which is known as the parameter marker. You must supply values for every parameter before executing the SQL statement.
The setXXX() methods bind values to the parameters, where XXX represents the Java data type of the value you wish to bind to the input parameter. If you forget to supply the values, you will receive an SQLException.
Each parameter marker is referred to by its ordinal position. The first marker represents position 1, the next position 2, and so forth. This method differs from that of Java array indices, which start at 0.
All of the Statement object's methods for interacting with the database (a) execute(), (b) executeQuery(), and (c) executeUpdate() also work with the PreparedStatement object. However, the methods are modified to use SQL statements that can take input the parameters.

Closing PreparedStatement Obeject:

Just as you close a Statement object, for the same reason you should also close the PreparedStatement object.
A simple call to the close() method will do the job. If you close the Connection object first it will close the PreparedStatement object as well. However, you should always explicitly close the PreparedStatement object to ensure proper cleanup.
PreparedStatement pstmt = null;
try {
String SQL = "Update Employees SET age = ? WHERE id = ?";
pstmt
= conn.prepareStatement(SQL);
. . .
}
catch (SQLException e) {
. . .
}
finally {
pstmt
.close();
}


The CallableStatement Objects:



Just as a Connection object creates the Statement and PreparedStatement objects, it also creates the CallableStatement object which would be used to execute a call to a database stored procedure.


Creating CallableStatement Object:



Suppose, you need to execute the following Oracle stored procedure:

CREATE OR REPLACE PROCEDURE getEmpName 
(EMP_ID IN NUMBER, EMP_FIRST OUT VARCHAR) AS
BEGIN
SELECT first INTO EMP_FIRST
FROM
Employees
WHERE ID
= EMP_ID;
END;
NOTE: Above stored procedure has been written for Oracle, but we are working with MySQL database so let us write same stored procedure for MySQL as follows to create it in EMP database:
DELIMITER $$

DROP PROCEDURE IF EXISTS
`EMP`.`getEmpName` $$
CREATE PROCEDURE
`EMP`.`getEmpName`
(IN EMP_ID INT, OUT EMP_FIRST VARCHAR(255))
BEGIN
SELECT first INTO EMP_FIRST
FROM
Employees
WHERE ID
= EMP_ID;
END $$

DELIMITER
;
Three types of parameters exist: IN, OUT, and INOUT. The PreparedStatement object only uses the IN parameter. The CallableStatement object can use all three.
Here are the definitions of each:
ParameterDescription
INA parameter whose value is unknown when the SQL statement is created. You bind values to IN parameters with the setXXX() methods.
OUTA parameter whose value is supplied by the SQL statement it returns. You retrieve values from theOUT parameters with the getXXX() methods.
INOUTA parameter that provides both input and output values. You bind variables with the setXXX() methods and retrieve values with the getXXX() methods.
The following code snippet shows how to employ the Connection.prepareCall() method to instantiate aCallableStatement object based on the preceding stored procedure:
CallableStatement cstmt = null;
try {
String SQL = "{call getEmpName (?, ?)}";
cstmt
= conn.prepareCall (SQL);
. . .
}
catch (SQLException e) {
. . .
}
finally {
. . .
}
The String variable SQL represents the stored procedure, with parameter placeholders.
Using CallableStatement objects is much like using PreparedStatement objects. You must bind values to all parameters before executing the statement, or you will receive an SQLException.
If you have IN parameters, just follow the same rules and techniques that apply to a PreparedStatement object; use the setXXX() method that corresponds to the Java data type you are binding.
When you use OUT and INOUT parameters you must employ an additional CallableStatement method, registerOutParameter(). The registerOutParameter() method binds the JDBC data type to the data type the stored procedure is expected to return.
Once you call your stored procedure, you retrieve the value from the OUT parameter with the appropriate getXXX() method. This method casts the retrieved value of SQL type to a Java data type.

Closing CallableStatement Obeject:

Just as you close other Statement object, for the same reason you should also close the CallableStatement object.
A simple call to the close() method will do the job. If you close the Connection object first it will close the CallableStatement object as well. However, you should always explicitly close the CallableStatement object to ensure proper cleanup.
CallableStatement cstmt = null;
try {
String SQL = "{call getEmpName (?, ?)}";
cstmt
= conn.prepareCall (SQL);
. . .
}
catch (SQLException e) {
. . .
}
finally {
cstmt
.close();
}

What are the advantages/disadvantages of Swing over AWT?

Swing provides a richer set of components than AWT. They are 100% Java-based.
AWT on the other hand was developed with the mind set that if a component or capability of a component wasn't available on one platform, it won't be available on any platform. Something quickly portable from platform x, to y, to z. Due to the peer-based nature of AWT, what might work on one implementation might not work on another, as the peer-integration might not be as robust. Many of the original AWT problems were traceable to differences in peer implementations.
This is not to say that there are less bugs in Swing, though most are out these days. Its just that if a bug exists in Swing, its the same problem on all platforms, which was not the case with AWT.

There are a few other advantages to Swing over AWT:
  • Swing provides both additional components and added functionality to AWT-replacement components
  • Swing components can change their appearance based on the current "look and feel" library that's being used. You can use the same look and feel as the platform you're on, or use a different look and feel
  • Swing components follow the Model-View-Controller paradigm (MVC), and thus can provide a much more flexible UI.
  • Swing provides "extras" for components, such as:
    • Icons on many components
    • Decorative borders for components
    • Tooltips for components
  • Swing components are lightweight (less resource intensive than AWT)
  • Swing provides built-in double buffering
  • Swing provides paint debugging support for when you build your own components
Swing also has a few disadvantages:

  • It requires Java 2 or a separate JAR file
  • If you're not very careful when programming, it can be slower than AWT (all components are drawn)
  • Swing components that look like native components might not act exactly like native components