Subject | Re: [Firebird-Java] Yet about code that works in 1.5.5 and doesn't in 2.0.1 (getResultSet) |
---|---|
Author | Roman Rokytskyy |
Post date | 2006-03-31T14:40:14Z |
> To better understand your comment: you said that "JDBC specification"Let's say, it was non-standard behavior in JDBC driver. It worked only in
> requires that "getResultSet();" doesn't work like before?
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 callGood question... basically, the question is whether we can treat
> "executeQuery" I have make something like this: "rs =
> stmt.executeQuery();". I understood that I don't have a way to call
> "getResultSet();" after this.
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