I am calling a stored procedure. When the procedure returns zero rows, following line returns "NULL" according to the documentation.
I need to return a non null resultset object even if there are no rows found. I have two questions.
1. Does "getResultset()" returns a null object when no rows are found or posibbly something else is wrong?
2. If CallableStatement returns null when no rows are found then what's the easiest way to create a "Resultset" empty object. When I try to create a new ResultSet object eclipse implements all methods in the interface. Can I do something llike this instead?
the getResultSet method returns the current result as a ResultSet object or null if the result is an update count or there are no more results,Normally statement.executeQuery executes and returns a single ResultSet object.returns you the Result set,getResultSet() gives you the current resultset
executeQuery() from the Statement interface cannot be called on PreparedStatement and CallableStatement, but PreparedStatement has an executeQuery() method that is specified in the interface. As for CallableStatement you are out of luck, getResultSet() is the only way of getting a ResultSet from it and it might return null on no results.
You cannot get an instance of ResultSet in any other way than through return values. ResultSet is an interface and according to the documentation no class implements it, that suggests that the actual implementation is either vendor specific or hidden somewhere in the depths of Java. Just add checks for null on the ResultSet all the way through your code and you are in business again.
Muhammad Imad Qureshi
posted 9 years ago
Thanks Phil and Grdihar
That's what I realized that executeQuery won't work. Following on number 2 from Philip. My problem is that I have to return a ResultSet object to a client software and it blows up when it receives a null value. I want to make sure that I return a non null resultset value. Apparently from your reply, I cannot control that. So something needs to be done on the client side. Is that correct?
Something needs to be done client side, because you cannot be sure that you will not get a null from the CallableStatement, and you cannot construct an empty ResultSet.
Generally it is not advisable to return ResultSets, or any JDBC object, to your code because it is easy to create resource problems that way. As soon as you close any Statement (including CallableStatement) any associated ResultSet is also closed. So returning them requires your Statement to remain open, but if you leave the scope where the Statement is defined you loose the reference but it still exists on the heap and the server because it was not closed.
If you have any control over the client code I recommend a rewrite to avoid return ResultSets, you might not get into trouble but I say "better safe than sorry". But as a minimum of have to deal with possible null returns.
While not recommended you can look into the actual need for CallableStatements, maybe PreparedStatements will work for you. Then executeQuery() becomes an option again, you do not need to touch the client code, and can return ResultSets without worrying about null.
Onion rings are vegetable donuts. Taste this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop