[jira] Commented: (DERBY-5) Network Server Protocol error when select fails and "order by" is specified

["A B (JIRA)" <de...@db.apache.org>]

     [ http://nagoya.apache.org/jira/browse/DERBY-5?page=comments#action_55107 ]
     
A B commented on DERBY-5:
-------------------------

This issue has been "quick fixed" with svn rev 56215.  However, I'm not calling it "resolved" yet because there is still a possible usage scenario where this fix won't work--namely, in cases where the buffer that we're trying to "clear" has already been transmitted to the client, thus making it impossible to "undo" the write.  Need to look at this and figure out 1) if that scenario is actually possible, and 2) if so, how do we fix it?

NOTE: This scenario was a problem even before rev 56215 was submitted, so we're still better off now than we were before.  Now, at least, simple cases like the one mentioned in the bug description should work...

> Network Server Protocol error when select fails and "order by" is specified
> ---------------------------------------------------------------------------
>
>          Key: DERBY-5
>          URL: http://nagoya.apache.org/jira/browse/DERBY-5
>      Project: Derby
>         Type: Bug
>   Components: Network Server
>     Versions: 10.0.2.0
>     Reporter: Tulika Agrawal

>
> Reporting for Army, filed on derby-dev list.
> If, when using the Network Server, one tries to execute a select 
> statement that fails because of an SQL exception (ex. divide-by-zero), 
> and if an "order by" clause is specified as part of the select, the 
> server will throw a distributed protocol exception, instead of the 
> appropriate error.
> Repro (using the "ij" utility)
> ij> connect 'jdbc:derby:net://localhost:1527/myDB:user=u;password=p;';
> ij> create table t1 (i int, j int);
> 0 rows inserted/updated/deleted
> ij> insert into t1 values (2,0);
> 1 row inserted/updated/deleted
> -- Without an "order by" it's fine...
> -- (22012 ==> "Attempt to divide by zero.", which is fine)
> ij> select {fn mod(i,j)} from t1;
> 1
> -----------
> ERROR 22012: DB2 SQL error: SQLCODE: -1, SQLSTATE: 22012, SQLERRMC: 22012
> -- With an order by, it dies...
> ij> select {fn mod(i,j)} from t1 order by 1;
> ERROR 58009: Execution failed due to a distribution protocol error that 
> caused deallocation of the conversation. A DRDA Data Stream Syntax Error 
> was detected. Reason: 0x13
> NOTES:
> The problem is in the DRDAConnThread.java file, "processCommands(...)" 
> method, in the "case CodePoint.OPNQRY" block of code. In the case of an 
> SQL exception, there's a call to "writer.clearBuffer()" that is used to 
> ensure that _only_ an OPNQFLRM is sent back to the client, not the 
> OPNQRYRM and/or QRYDSC that may have been written to buffer before the 
> OPNQFLRM. That call to "clearBuffer" has to be replaced with something 
> smarter, so that instead of doing a full clear (which causes the problem 
> shown above), it only backs out the buffer writes that it has made since 
> beginning the "case CodePoint.OPNQRY" block...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira