[
http://issues.apache.org/jira/browse/DERBY-1101?page=comments#action_12370196 ]
Knut Anders Hatlen commented on DERBY-1101:
-------------------------------------------
OK, I see your point. I'm not able to tell whether or not you are
right, though...
One way to implement getHoldability() without being dependent on
getStatement() is to add a holdability variable to EmbedResultSet and
put something like this in the constructor:
if (theResults instanceof TemporaryRowHolderResultSet ||
!theResults.getActivation().getResultSetHoldability()) {
holdability = JDBC30Translation.CLOSE_CURSORS_AT_COMMIT;
} else {
holdability = JDBC30Translation.HOLD_CURSORS_OVER_COMMIT;
}
Do you think this is a better approach?
> ResultSet.getHoldabilty will return incorrect value when the ResultSet is
> obtained from a procedure call
> --------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1101
> URL: http://issues.apache.org/jira/browse/DERBY-1101
> Project: Derby
> Type: Bug
> Components: JDBC
> Versions: 10.2.0.0
> Reporter: Daniel John Debrunner
> Priority: Minor
> Attachments: testderby1101.java
>
> EmbedResultSet40.getHoldability returns the holdability of the statement
> returned by ResultSet.getStatement().
> When a ResultSet is created by a procedure call, its holdability may not
> match the holdability of the Statement that called the procedure, which is
> probably what ResultSet.getStatement() should return.
> This may not be exposed as a bug yet, but I think this method should be
> directly obtaining the holdability of the ResultSet using the
> Activation.getResultSetHoldability() method, rather than through a Statement.
> Seems a safer approach.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
