Terry,

1. As far as I can see your change shouldn't break anything.

2. What do you consider "the 'official' version of interclient"?
Currently there are two active CVS trees, Firebird's and Inprise's.
For the time being only Inprise stuff is allowed to commit to the
Inprise tree, while Firebird is open for everybody.

3. I wouldn't mind applying the change to Firebird, but I would also
like to hear what the "Inprise side" thinks about it - it would be
helpful to do those changes in sync if possible.
So Inpr.., err, Shaunak, what do you think? <g>

Regards, Torsten

--- In IB-Java@egroups.com, "Terry Child" <tmchild@g...> wrote:
>
> Hi All
>
> I know I've mentioned this before but it didn't get resolved:
>
> ResultSet.next() throws an exception when it is called after
previously
> returning false. All of the other JDBC drivers I've tried return
false again,
> which I would argue is the right thing to do. If it's not a great
deal of work
> could someone who knows the source change it to return false?
>
> I'm using a modified version where I just return false in
> ResultSet.getNextCursorPosition() instead of throwing the
Exception, but I don't
> know the code well and this may break something else:
>
> private boolean getNextCursorPosition () throws
java.sql.SQLException
> {
> // >>> To handle multiple result sets in the future,
> // >>> we'll need to detect that the "buffer is exhausted"
> // >>> and send FETCH_ROWS for the first next() of the next
result set.
>
> if (recvMsg_ == null) return false;
> /* throw new InvalidOperationException
> (ErrorKey.invalidOperation__read_at_end_of_cursor__); */
> ...
>
> The reason I would like this change is that I'm using the open
source Castor O/R
> mapping tool and would really like to use it with the 'official'
version of
> interclient, as would alot of other developers. Castor relies on
the above
> ResultSet behaviour and works with Oracle,Postgres etc. It would
seem like a
> small change to make to open Interbase up to the Castor community.
>
> Regards
>
> Terry