[ http://issues.apache.org/jira/browse/DERBY-1361?page=comments#action_12417059 ]
Andreas Korneliussen commented on DERBY-1361: --------------------------------------------- For the scrollable case, I found two problems: 1. The network client will do a parsing of the SQL and reposition the cursor when there is a positioned update (if it is a scrollable cursor). Since the cursor is repositioned, no exception is thrown when doing it immediately after a commit. The repositioning logic can be removed. 2. Scrollable cursors will not reposition the scancontroller of indexscans. This means that the scancontroller for the index may be closed. Using the scancontroller to depend on this logic does not seem sufficient. I will go in another direction: on a commit, every activations will be notified. The activations has references to a ResultSet, and they can notify the resultsets that they should be positioned between the current row and the next row (this can be done by setting currentRow=null) As for the two different error messages, I think that this change may force me to choose one of these. It does not seem to be entirely deterministic when I get one and not the other. I think the correct message is the one with SQLSTate 24000. > positioned updates and deletes allowed after a commit without repositioning > the cursor - if the table is indexed on the columns selected > ---------------------------------------------------------------------------------------------------------------------------------------- > > Key: DERBY-1361 > URL: http://issues.apache.org/jira/browse/DERBY-1361 > Project: Derby > Type: Bug > Components: JDBC > Versions: 10.2.0.0 > Environment: Java 1.4 > Reporter: Andreas Korneliussen > Assignee: Andreas Korneliussen > > After a commit, the cursor should be positioned before the next row (not on a > row). However in Derby 10.2, I now see the following behavior if the table > has an index on the selected columns: > ij> create table t (id int primary key); > ij> commit; > ij> insert into t values 1,2,3,4,5,6,7,8,9; > 9 rows inserted/updated/deleted > ij> commit; > ij> get cursor c1 as 'select * from t for update'; > ij> next c1; > ID > ----------- > 1 > ij> commit; > ij> update t set id=id+1000 where current of c1; > 1 row inserted/updated/deleted > ij> commit; > ij> update t set id=id+1000 where current of c1; > 1 row inserted/updated/deleted > ij> > The expected behavior is that the UPDATE .. WHERE CURRENT OF fails with: > ERROR 24000: Invalid cursor state - no current row. > The problem applies to both scrollable and forward-only updatable cursors. > Note: If the table is created *without* the index, I do see the expected > behavior. > I am marking this as a regression, since this issue is not reproducible on > older, released versions of derby (I have tested with 10.1.2.1). -- 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
