db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik" <Dag.Wan...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-610) After commit, holdable result set cursor used in positioned update can't access row
Date Mon, 10 Oct 2005 04:33:53 GMT

Hi Dan,

Daniel> I think the current behaviour is correct. After a commit the
Daniel> result set is open but is not positioned on a row. The result
Daniel> set must be re-positioned with a next() or other method before
Daniel> acessing a row or modifying it with a positioned update or
Daniel> delete. I think this may be from the SQL standard, or is it
Daniel> the JDBC standard?

Thanks, you may be right...I'll go hunt for it... 

The problem in the present case, of course, is that a new next() would
take you past the row for which an update was intended. Since forward
only forbids relative(0), I can't see a way to reposition the row
correctly in this case. With scrollable, updatable result sets it
could possibly work, though (using relative(0)). Hmm. It seems less than
orthogonal, in case what you suggest it accurate.

Just tried to access the row using ResultSet#getInt(1) immediately
after the commit(). That gave no error. Are you suggesting it should
have done so?

I also wonder what the cursor position would be "in the meantime",
just after the commit? Prior to the initial next(), the cursor is defined
to be immediately prior to the first row: so where is it just after a
commit, if it does not stay "in place", in some limbo state?

I'll go dig some more into it..


Daniel> The bug 4515 (Cloudscape bug tracking system) was fixed, I think to return the
correct error as you are seeing.
Daniel> > After commit, holdable result set cursor used in positioned update can't 
access row
Daniel> > ------------------------------------------------------------------------------------
Daniel> >
Daniel> >          Key: DERBY-610
Daniel> >          URL: http://issues.apache.org/jira/browse/DERBY-610
Daniel> >      Project: Derby
Daniel> >         Type: Bug
Daniel> >   Components: SQL
Daniel> >     Versions:
Daniel> >     Reporter: Dag H. Wanvik
Daniel> >     Priority: Minor
Daniel> >  Attachments: Main.java
Daniel> >
Daniel> > Using the embedded driver, with autocommit off, and holdability for a
Daniel> > updatable result set  (HOLD_CURSORS_OVER_COMMIT), I first
Daniel> > position on a row in the result set, and then commit the
Daniel> > transaction. The result set should still be open since holdability is
Daniel> > active.  However, when accessing the result set using a named cursor
Daniel> > in a subsequent "Positioned update" statement, Derby returns an error
Daniel> > message: "Invalid cursor state - no current row" (SQLState 24000).
Daniel> > Please see the self-contained repro case in the attachment for
Daniel> > details.
Daniel> > It appears the problem is related to reopening of holdable result sets
Daniel> > after a commit. During normal use of result sets, the ResultSet#next()
Daniel> > operation will make sure the result set is opened (after locks were
Daniel> > released at commit time). Apparently no such reopening is performed in
Daniel> > the "positioned update" case. (small detail: Note that in the
Daniel> > "positioned update" case, the reopening is for accessing the current
Daniel> > row (again), not the next - I am not sure if that matters, though).
Daniel> -- 
Daniel> This message is automatically generated by JIRA.
Daniel> -
Daniel> If you think it was sent incorrectly contact one of the administrators:
Daniel>    http://issues.apache.org/jira/secure/Administrators.jspa
Daniel> -
Daniel> For more information on JIRA, see:
Daniel>    http://www.atlassian.com/software/jira
Dag H. Wanvik
Sun Microsystems, Web Services, Database Technology Group
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43496/+47 73842196, Fax:  +47 73842101

NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact
the sender by reply email and destroy all copies of the original

View raw message