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
