closeOnCompletion doesn't work properly in MySQL JDBC 5.1.32 - java

I have a snippet like this:
Statement statement = connection.createStatement();
ResultSet rs = statement.executeQuery("SELECT * FROM table_A");
statement.closeOnCompletion();
System.out.println(statement.isCloseOnCompletion());
rs.close();
System.out.println(statement.isClosed());
After closeOnCompletion is invoked, I expect the statement to be closed, as its result set is closed. However, it just shows "false" when checking statement.isClosed().
Did I misunderstand the jdk doc? as it says: closeOnCompletion() Specifies that this Statement will be closed when all its dependent result sets are closed.
===========================
Update:
It turns out to be my carelessness. The last statement actually returns a result of expected "true". So it's no longer an issue

Since Statement is depend on result I would suggest this
Statement statement = connection.createStatement();
ResultSet rs = statement.executeQuery("SELECT * FROM table_A");
rs.close();
statement.close();
System.out.println(statement.isClosed());
This is applicable if your ultimate want is to close statement, if your question is why statement is not closing even when called onexit, then better to refer javadocs.

Related

Getting resultset twice from statement

I understand that using statement.getResultSet() returns the result set as well as statement.executeQuery() but what happens if both are used like executeQuery() is called first and then getResultSet() is called after does it work or will it throw an exception that the result set has already been returned?
Please look into this
executeQuery: Returns one ResultSet object.
ResultSet rs = stmt.executeQuery(query);

Is it a good practice to put ResultSet into a nested try-with-resources statement after Java7?

According to doc of http://docs.oracle.com/javase/7/docs/api/java/sql/Statement.html#close() ,
When a Statement object is closed, its current ResultSet object, if
one exists, is also closed.
But accoring to Must JDBC Resultsets and Statements be closed separately although the Connection is closed afterwards? , it is seems to be a good practice to explicitly close Connection Statement and ResultSet .
If we still need to close ResultSet, we may need to have a nested try-with-resources statement since we may probably set parameter for Statement like this:
try (Connection conn = connectionProvider.getConnection();
PreparedStatement pstmt = conn.prepareStatement(sql) {//resources of conn and pst
setPrepareStatementParameter(pstmt, kvs);//need to set parameters, so I have to put ResultSet into another try-with-resources statement
try (ResultSet res = pstmt.executeQuery()) {
..............
}
}
Question:
Does put the ResultSet into a separate try-with-resources statement worth anything since the doc states that closing Statement will close the ResultSet
Your example covers too limited a range of the interactions between Connections, Statements, and ResultSets. Consider the following:
try (Connection conn = connectionProvider.getConnection();
PreparedStatement pstmt = conn.prepareStatement(sql);) {
for (int i = 0; i < kvs.length; i++) {
setPrepareStatementParameter(pstmt, kvs[i]);
// do other stuff
// Place the ResultSet in another try with resources
// to ensure the previous iteration's ResultSet
// is closed when the next iteration begins
try (ResultSet res = pstmt.executeQuery()) {
..............
}
}
}
In the above example, the PreparedStatement is parametrized and executed a kvs.length number of times within the for-loop. Imagine a case in which the parametrization process, for any reason, took a significant length of time. Note that closing the PreparedStatement would do us no good since we want to reuse the compiled SQL statement at every iteration of the for-loop. Then surely nesting the ResultSet into its own try-with-resources block---thus ensuring the prior iteration's ResultSet is closed but the PreparedStatement remains open---is a worthwhile effort.
Yes, you should close or put a try-resources for result set.
Why?
I quote what I've read from other answer that makes a lot of sense for me.
In theory closing the statement closes the result set.
In practice, some faulty JDBC driver implementations failed to do so.
Check the full answer here:
https://stackoverflow.com/a/45133734/401529

No return data from PreparedStatement query

I am trying to do a SELECT using PreparedStatement, but not getting any results back, despite the data being present. If I use Statement instead, I get the desired results, so not sure why I don't get anything with the PreparedStatement.
Any ideas?
Here is my code:
String species = "Snail";
PreparedStatement preparedStatement = con.prepareStatement("Select * from lifeforms where species=?",PreparedStatement.RETURN_GENERATED_KEYS);
preparedStatement.setString(1, species);
preparedStatement.execute();
ResultSet resultSet = preparedStatement.getGeneratedKeys();
Also - I have tried just
resultSet = preparedStatement.execute();
But this won't compile, saying I must change resultSet to expect a boolean value.
Any insights into this would be greatly appreciated.
Sorry if this is something obvious, but I have read the docs until I am almost unconscious, and I'm only just learning java.
The execute() functon returns a boolean value so u won't be able to put this in an object of resultset, if you want to execute a select statement you have to use executeQuery().
Ah so I have finally found the answer to this question - in case anyone else is stuck on the same thing..
The execute() method has no return value, although the compiler was suggesting it expected a boolean return value. Maybe it just returns true or false for successful or not?
The executeUpdate() method returns an int value of the number of records updated/inserted or deleted.
To get the result set of a query statement (e.g. Select * from someTable), use the
ResultSet rs = preparedStatement.executeQuery() method.
This will return the actual query results into a ResultSet variable.

Create method which returns resultset from sql query

I have a little problem with creating a method which takes String as parameter and return ResultSet after execute the query.Here is an example actually what I'm trying to do :
public ResultSet executeSQLQuery(String query){
ResultSet rs = sqliteDb.rawQuery(query,null);;
return rs;
}
Something like this, but it says that I have to convert rs to cursor type, but I need to return RS. Any ideas how to get the things to work?
possible duplicate
The result set isn't available, at least for now, in sqlite. It all depends on exactly what information you want from the ResultSet or ResultSetMetaData, etc, but there are other means of obtaining almost the same information.
check this link
to get resultset from pre-complie statement in android

How can I get previous item in resultset?

Suppose we have this query:
ResultSet result = ("select * from table_name");
Now we can get information from result in this form
while(result.next())
{
.
.
.
}
but in this form we can go forward. Now I want to know if it possible that result get back?
For example we get information name='sam', fname='nic'. And for next I want go back and get this information again.
Is it possible?
Yes, JDBC supports that. You need to a scrollable resultset.
Something like this:
Statement st = conn.createStatement(
ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY
);
ResultSet rs = st.executeQuery("select * from table_name");
Then you just use ResultSet object rs to move within your results:
first
absolute
last
next
previous
Are methods that will help you navigate.
When you create a Statement without passing parameters to it, it defaults to ResultSet.TYPE_FORWARD_ONLY.
Statement st = con.createStatement();
If you want to be able to scroll back you set the first parameter to either ResultSet.TYPE_SCROLL_INSENSITIVE or ResultSet.TYPE_SCROLL_SENSITIVE. (Insensitive or sensitive in regard to changes to the database by others.)
Statement st = con.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE);
CONCUR_UPDATABLE will allow you to update the ResultSet if you want, unless you do not need to, i which case you set it to CONCUR_READ_ONLY.
Read this.

Categories