Subject Re: [Firebird-Java] Yet about code that works in 1.5.5 and doesn't in 2.0.1 (getResultSet)
Author Roman Rokytskyy
> To better understand your comment: you said that "JDBC specification"
> requires that "getResultSet();" doesn't work like before?

Let's say, it was non-standard behavior in JDBC driver. It worked only in
auto-commit mode due to some restrictions that we had. Those restrictions
were removed in Jaybird 2.0 and full JDBC compatibility was restored.

> If yes, may I suppose "getResultSet();" is a deprecated method?

No, it is not. Only that you use it in a quite unique way.

There are two main usages for this method that are described in the
specification:

a) in combination with Statement.execute(String) to fetch the result set if
the execute() method returned true. Then you can get the current result set.

b) in combination with the Statement.getMoreResults() to move to the next
result set (mainly callable statements, but not in Firebird). After that you
call that method to get the next result set.

Also the specification says "getResultSet() - Retrieves the current result
as a ResultSet object. This method should be called only once per result."

> Because looking in you code for AbstractStatement, if I call
> "executeQuery" I have make something like this: "rs =
> stmt.executeQuery();". I understood that I don't have a way to call
> "getResultSet();" after this.

Good question... basically, the question is whether we can treat
executeQuery() as implicit call to getResultSet() (both method obtain result
set, can be considered equivalent) and whether we should enforce what
specification says.

Since you say that all other drivers do not enforce this, I guess we can
relax this thing too. I have checked Oracle, they do not check when
getResultSet() method is called. Also I have checked JDBC CTS suite, there's
no code that checks this behavior. So I guess, we can ignore this part too.

But if you're going to use getResultSet() method, I'd suggest to switch to
Statement.execute(....) anyway, since that is the scenario described in JDBC
specification and you can be sure that it will be correctly handled by all
drivers.

Roman