db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1266) Client: Attempted deleteRow or updateRow while on insert row gives wrong error message
Date Thu, 04 May 2006 12:15:18 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1266?page=comments#action_12377779 ] 

Dag H. Wanvik commented on DERBY-1266:
--------------------------------------

David> "XJ120.S=This method cannot be invoked while the cursor is on
David> the insert row, if the cursor is not on a valid row, or if this
David> ResultSet object has a concurrency of CONCUR_READ_ONLY."

I checked the *embedded* client: its method
EmbedResultSet#checkNotOnInsertRow is called from

    deleteRow,
    updateRow and 
    cancelRowUpdates (I forgot to mention that this method has the
                      same issue as well) 

In the embedded client, checkNotOnInsertRow gives
SQLState.NO_CURRENT_ROW (24000), whose wording in English is "Invalid
cursor state - no current row.".

That's not very precise, but shouldn't we strive to keep the clients in
synch?  I guess I would prefer to use the same state for both clients...

I notice XJ120 which you mention is only ever used as a catch-all for
checks in the client's refreshRowX method, which currently does
nothing for the result sets we implement.. But it does employ XJ120
(CURSOR_CANNOT_INVOKE_ON_INSROW_OR_INVALIDROW_OR_READONLY).

I think the checking in refreshRow should be split: If position is on
insertRow, we should throw same message as elsewhere in client (and
same as embedded); if one of the other error conditions is hit, you
could throw XJ120, but simplify its name and wording to invalid row,
which seems to be what's left of it (position is before first or after
last). Updatability is now is checked by the preceding test (call to
checkForUpdatableResultSet).  But then again, if invalid position is
the only condition remaining, I guess we can do away with XJ120
alltogether... and just use 24000.

BTW, I notice that embedded throws an exception for refreshRow, it
seems the client does not....

> Client: Attempted deleteRow or updateRow while on insert row gives wrong error message
> --------------------------------------------------------------------------------------
>
>          Key: DERBY-1266
>          URL: http://issues.apache.org/jira/browse/DERBY-1266
>      Project: Derby
>         Type: Bug

>   Components: Network Client
>     Versions: 10.2.0.0
>  Environment: any
>     Reporter: Dag H. Wanvik
>     Assignee: David Van Couvering
>     Priority: Minor
>      Fix For: 10.2.0.0

>
> This fragment from deleteRowX shows the problem:
> > if (isOnInsertRow_) {
> >       throw new SqlException(agent_.logWriter_, 
> >           new MessageId(SQLState.CURSOR_NOT_POSITIONED_ON_INSERT_ROW));
> > }
> It should be the opposite: the problem is that the cursor *is* on the
> insert row, not that it isn't.
> These is a similar error in updateRowX.
> The client master files for updatableResultSet show the problem, so
> the masters are wrong, too.
> > Negative Test 39.a - run updateRow on insertRow
> > SQL State: XJ086
> > Got expected exception: This method cannot be invoked while the
>   cursor is not on the insert row or if the concurrency of this 
>   ResultSet object is CONCUR_READ_ONLY. 

-- 
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


Mime
View raw message