I'm executing a few SELECTs in a row and I'm wondering how I should handle the PreparedStatements.
Example code:
//Connection conn is already declared
PreparedStatement pstmt = null;
ResultSet rset = null;
try {
String sql = "SELECT ...";
pstmt = conn.prepareStatement(sql);
pstmt.setString(1, someVar);
rset = pstmt.executeQuery();
// Use ResultSet
// A different query
sql = "SELECT ...";
pstmt = conn.prepareStatement(sql);
pstmt.setString(1, someVar);
rset = pstmt.executeQuery();
// Use ResultSet
} catch (SQLException e) {
// Handle
} finally {
if (rset != null)
rset.close();
if (pstmt != null)
pstmt.close();
if (conn != null)
conn.close();
}
Now the question is, would it be better to close the PreparedStatements after each usage/use different statements or would it make absolutely no difference?
I've found some information about reusing a PreparedStatement that always has the same query but I'm not sure about using different queries.
You're not using the same PreparedStatement, the factory method Connection.prepareStatement is returning you a new instance each time you call it. PreparedStatement.executeQuery is doing the same with ResultSet. You are just using the same variables.
This means you're leaking resources - the first PreparedStatement and ResultSet - every time this method is called, which are never being closed.
My recommendation would be to use Spring's JdbcTemplate which will handle these database resources correctly for you and you break your code into two methods.
Related
I have such a method:
private static ResultSet select (Connection connection, String query) {
PreparedStatement selectQuery = null;
ResultSet resultSet = null;
try {
selectQuery = connection.prepareStatement(query);
resultSet = selectQuery.executeQuery();
selectQuery.close();
} catch (SQLException e) {
System.out.println(e);
}
return resultSet;
}
The thing is that the resultSet is always empty when I close the preparedStatement.
If I comment out the line with clothing preparedStatement //selectQuery.close(); everything is fine.
I close it after assigning value to the resultSet. So why it's empty?
A ResultSet is associated with an executed Statement. Close the statement and the resultset, with any data in it is cleared.
You need to process the resultset before you close the statement, so your approach will not work.
You have to iterate through the ResultSet. You have an high level example right here:
try{
// execute the query
ResultSet rs = st.executeQuery(query);
// iterate through the result set
while (rs.next())
{
// Replace with your data
int id = rs.getInt("id");
String name = rs.getString("name");
// do stuff with the result set, add to a List of objects (for example)
}
selectQuery.close();
}catch(SQLException e) {
System.out.println(e);
}
You have not to close the statement before having retrieved the data of the resultset otherwise these may be not accessible.
When you call this method, its ResultSet objects are closed.
So, only when you are finished using a Statement, call the Statement.close() method.
The close should be performed in a finally statement.
In this way you are ensure that you don't worry to wonder when close it.
With your actual code :
private static ResultSet select (Connection connection, String query) {
PreparedStatement selectQuery = null;
ResultSet resultSet = null;
try {
selectQuery = connection.prepareStatement(query);
resultSet = selectQuery.executeQuery();
} catch (SQLException e) {
System.out.println(e);
}
finally {
if (selectQuery != null) { selectQuery.close(); }
}
return resultSet;
}
}
A better alternative is using a try-with-resources statement :
try (Statement stmt = con.createStatement()) {
// ...
}
Because the javadoc says so:
Note: When a Statement object is closed, its current ResultSet object, if one exists, is also closed.
Rationale: The stated behavior of Statement.close() is to release all resources. One of those resources is the server-side cursor for reading the results. But if you release that, then the ResultSet has nothing to pull data from.
I'm curious how you are determining that the (closed) ResultSet is "empty". It looks like all operations on a closed ResultSet (apart from close()) ought to throw an exception.
I want to read my Blob data in chunks using getBinaryStream() method, as I expect some blobs to be big, so I produced following method:
public InputStream getBlob(Long id) throws SQLException {
PreparedStatement stmt = null;
ResultSet rs = null;
try {
stmt = connection.prepareStatement("select blob_contents from some_table where id = ?");
stmt.setLong(1, id);
rs = stmt.executeQuery();
if (rs.next()) {
return rs.getBinaryStream("blob_contents");
} else {
return null;
}
} finally {
if (stmt != null) {
stmt.close();
}
if (rs != null) {
rs.close();
}
}
}
Is it safe to close the resultSet rs and statement stmt in finally block and then return the stream from this method? Is it safe to process the stream after that?
What I know already:
In my junits based on h2 database it works.
My code works ok on oracle db.
I've found somthing about blobs in ResultSet's javadocs, but I'm not sure if this applies to the getBinaryStream method:
The closing of a ResultSet object does not close the Blob, Clob or NClob objects created by the ResultSet. Blob, Clob or NClob objects remain valid for at least the duration of the transaction in which they are creataed, unless their free method is invoked.
If I do something like
try (
Connection conn = Database.getConnection();
PreparedStatement ps = conn.prepareStatement("SELECT * FROM table WHERE something = ? LIMIT 1");
) {
ps.setString(1, "hello world");
ResultSet results = ps.executeQuery();
if(results.next()) {
// blah
}
} catch(SQLException e) {
e.printStackTrace();
}
Will the ResultSet still be closed when the PreparedStatement is closed, or will I still have to explicitly close the ResultSet also?
As per javax.sql.Statement.close() method's JavaDoc:
Note:When a Statement object is closed, its current ResultSet object, if one exists, is also closed.
So, answering your question - yes, ResultSet will be automatically closed in your case, because related Statement is closed in try-with-resources block.
However, please note that explicitly closing ResultSets is a good practice which is recommended to follow, so your modified code following good practices would look like:
try (
Connection conn = Database.getConnection();
PreparedStatement ps = prepareStatement(conn, "SELECT * FROM table WHERE something = ? LIMIT 1", param);
ResultSet results = ps.executeQuery();
) {
if(results.next()) {
// blah
}
} catch(SQLException e) {
e.printStackTrace();
}
private static PreparedStatement prepareStatement(Connection connection, String sql, String param) throws SQLException {
final PreparedStatement ps = conn.prepareStatement(sql);
ps.setString(1, param);
return ps;
}
Always As a good practice, try to close your ResultSets and PreparedStatements. In a finally block. Every single time , managing exceptions, so you won't leave resources unattended (is a common source of leaks).
Unless you inject them to the method, hence the calling method probably needs them.
EDIT: Stand corrected. If resultset was created as try-with-resource, will die with your PS.
I am using following method for calculating payroll by using jdbc but "ORA-01008: not all variables bound" error is not removing.
Any idea please?
I am using following code
public double getPayroll(){
ResultSet rs = null;
ResultSet rs1 = null;
ResultSet rs2 = null;
Connection conn = null;
PreparedStatement pstmt = null;
try {
conn = getDBConnection();
double dailyPay=0,basicPay=0,payroll2=0;
int houseRent=0,convAllow=0,noOfPresents=0,empId=0;
String q = "select e_id from employee";
pstmt = conn.prepareStatement(q);
rs = pstmt.executeQuery();
while (rs.next()) {
empId=rs.getInt(1);
String q1 = "select count(att_status) from attendance where att_status='p'";
pstmt = conn.prepareStatement(q1);
rs1 = pstmt.executeQuery(q1);
while(rs1.next()){
noOfPresents=rs1.getInt(1);
String q2 = "select e_salary,e_house_rent,e_conv_allow from employee where e_id=?";
pstmt = conn.prepareStatement(q2);
pstmt.setInt(1,empId);
rs2 = pstmt.executeQuery(q2);
while(rs2.next()){
dailyPay=rs2.getInt(1)/22;
houseRent=rs2.getInt(2);
convAllow=rs2.getInt(3);
basicPay=dailyPay*noOfPresents;
payroll2+=basicPay+houseRent+convAllow;
}
}
}
return payroll2;
}catch (Exception e) {
e.printStackTrace();
return 0.0;
} finally {
try {
rs.close();
pstmt.close();
conn.close();
} catch (Exception e) {
e.printStackTrace();
}
}
}
Your problem is here:
rs2 = pstmt.executeQuery(q2);
You're telling the PreparedStatement to execute the SQL q2, rather than executing the SQL previously prepared. This should just be:
rs2 = pstmt.executeQuery();
This is a fairly common mistake, caused mainly by the bad class design of java.sql.Statement and its subtypes.
As #RMT points out, you make the same mistake here:
rs1 = pstmt.executeQuery(q1);
This doesn't matter so much, since there are no placeholders in q1, so the SQL executes as-is. It's still wrong, though.
Lastly, you should consider calling close() on the first PreparedStatement, before re-assigning the pstmt variable to another one. You risk a leak if you don't do that.
pstmt = conn.prepareStatement(q2);
pstmt.setInt(1,empId);
rs2 = pstmt.executeQuery(q2);
You have already created the prepared statement with the query q2 and bound the variable empId to it. if you now invoke pstmt.executeQuery(q2), the variable binding is lost. The JDBC driver probably parses the unbound sql q2 when you execute pstmt.executeQuery(q2).
One reason might be that you cannot re-use the instance of pstmt like that. You have to use a separate PreparedStatement instance in each level of the loop.
Are you aware that this can be done with just a single statement as well?
Edit:
Assuming there is a relation between employee and attendance, something like this would return the sum in a single request:
select sum( (e_salary / 22) * att_count + e_house_rent + e_conv_allow )
from (
select emp.e_salary
emp.e_house_rent,
emp.e_conv_allow,
(select count(att.att_status) from attendance att where att.e_id = mp.e_id) s att_count
from employee emp
) t
If indeed attendance is not linked to employee, just leave out the where clause in the nested select.
UPDATE TESTCP SET CP_KEY2 =?, CP_DESC =?, CP_MAKER =?, CP_MAKER_DT =SYSDATE, CP_STATUS ='M' WHERE CP_LANGUAGE = ? AND CP_ENG_CODE = ? AND CP_KEY1 =? AND CP_LANGUAGE =?
In the above query we have 7 in parameter but if in your java code PreparedStatement you have set only 6 parameter values .
That time also this error will occur.
I'm doing a simple preparedstatement query execution and its throwing me this error:
java.sql.SQLException: Use of the executeQuery(string) method is not supported on this type of statement at net.sourceforge.jtds.jdbc.JtdsPreparedStatement.notSupported(JtdsPreparedStatement.java:197) at net.sourceforge.jtds.jdbc.JtdsPreparedStatement.executeQuery(JtdsPreparedStatement.java:822) at testconn.itemcheck(testconn.java:58)
Any ideas what i'm doing incorrectly? thanks in advance
here is the code:
private static int itemcheck (String itemid ) {
String query;
int count = 0;
try {
Class.forName("net.sourceforge.jtds.jdbc.Driver");
con = java.sql.DriverManager.getConnection(getConnectionUrl2());
con.setAutoCommit(false);
query = "select count(*) as itemcount from timitem where itemid like ?";
//PreparedStatement pstmt = con.prepareStatement(query);
//pstmt.executeUpdate();
PreparedStatement pstmt = con.prepareStatement(query);
pstmt.setString(1,itemid);
java.sql.ResultSet rs = pstmt.executeQuery();
while (rs.next()) {
count = rs.getInt(1);
System.out.println(count);
} //end while
}catch(Exception e){ e.printStackTrace(); }
return (count);
} //end itemcheck
A couple of things are worth checking:
Use a different alias. Using COUNT as an alias would be asking for trouble.
The query object need not be passed twice, once during preparation of the statement and later during execution. Using it in con.prepareStatement(query); i.e. statement preparation, is enough.
ADDENDUM
It's doubtful that jTDS supports usage of the String arg method for PreparedStatement. The rationale is that PreparedStatement.executeQuery() appears to be implemented, whereas Statement.executeQuery(String) appears to have been overriden in PreparedStatement.executeQuery() to throw the stated exception.
So...
PreparedStatement pstmt = con.prepareStatement(query);
pstmt.setString(1,itemid);
java.sql.ResultSet rs = pstmt.executeQuery(query);
Unlike Statement, with PreparedStatement you pass the query sql when you create it (via the Connection object). You're doing it, but then you're also passing it again, when you call executeQuery(query).
Use the no-arg overload of executeQuery() defined for PreparedStatement.
So...
PreparedStatement pstmt = con.prepareStatement(query);
pstmt.setString(1,itemid);
java.sql.ResultSet rs = pstmt.executeQuery();