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

  A new issue has been created in JIRA.

View the issue:

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

   Reporter: Tulika Agrawal

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

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


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:

If you want more information on JIRA, or have a bug to report see:

View raw message