db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From derby-...@db.apache.org
Subject [jira] Created: (DERBY-5) Network Server Protocol error when select fails and "order by" is specified
Date Tue, 28 Sep 2004 00:21:32 GMT
Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/DERBY-5

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: DERBY-5
    Summary: Network Server Protocol error when select fails and "order by" is specified
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Derby
 Components: 
             Network Server
   Versions:
             10.0.2.0

   Assignee: 
   Reporter: Tulika Agrawal

    Created: Mon, 27 Sep 2004 5:20 PM
    Updated: Mon, 27 Sep 2004 5:20 PM

Description:
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...



---------------------------------------------------------------------
JIRA INFORMATION:
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

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


Mime
View raw message