[ http://issues.apache.org/jira/browse/DERBY-1468?page=all ]
Knut Anders Hatlen updated DERBY-1468:
--------------------------------------
Attachment: derby-1468-v1.diff
derby-1468-v1.stat
The attached patch (v1) disables pre-fetching for LMTBLKPRC when QRYROWSET=0.
Army could you please see if solves the issue with the ODBC driver?
Since there is no way I know of to reproduce the bug with the network client
driver, I have added a test case to the protocol test which sends an OPNQRY for
a scrollable cursor with QRYROWSET=0. The test case fails without the patch and
succeeds with the patch. I think the test case mimics the behaviour of the ODBC
driver.
One thing to note about the patch: It does revert the handling of the specific
case to pre-822 behaviour, but it does nothing with writeQRYDTA and writeFDODTA
to make them handle QRYROWSET=0. writeQRYDTA() can still be called with
QRYROWSET=0 on EXCSQLSTT. I'm not sure whether that is a problem, and the code
that enables this was not touched by DERBY-822. EXCSQLSTT should probably have
a similar fix for completeness. (A possible way to try to provoke this with the
ODBC driver could be to execute a stored procedure that returns a scrollable
result set.)
Derbyall runs cleanly with the patch.
> Server returns data when it receives a QRYROWSET value of zero on an OPNQRY,
> which doesn't follow DRDA protocol.
> ----------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1468
> URL: http://issues.apache.org/jira/browse/DERBY-1468
> Project: Derby
> Type: Bug
> Components: Network Server
> Versions: 10.2.0.0
> Reporter: A B
> Assignee: Knut Anders Hatlen
> Attachments: derby-1468-v1.diff, derby-1468-v1.stat
>
> When a client sends a QRYROWSET value of zero to the server, DRDA indicates
> that the server should not return any rows. But the current Derby Server
> treats a qryrowset value of 0 (zero) the same as it does a value of 1 (one)
> and thus performs pre-fetching (as of DERBY-822), which it shouldn't do.
> As a result, clients that send a QRYROWSET of 0 and do not expect data could
> see unexpected results--for example, the DB2 ODBC driver will return the
> first row of data twice for scrollable cursors because of this issue.
> Relevant discussion:
> http://article.gmane.org/gmane.comp.apache.db.derby.devel/22659
> Some quotes from DRDA manuals:
> 1) DRDA Manual v3 for OPNQRY:
> The qryrowset parameter specifies whether a rowset of rows is to be returned
> with the command. This is only honored for non-dynamic scrollable cursors
> (QRYATTSNS not equal to QRYSNSDYN) and for non-scrollable cursors conforming
> to the limited block query protocol. The target server fetches no more than
> the requested number of rows. It may fetch fewer rows if it is restricted by
> extra query block limits, or if a fetch operation results in a negative
> SQLSTATE or an SQLSTATE of 02000.
> 2) Page 698 of V.3 says:
> A QRYROWSET value of zero on the OPNQRY and EXCSQLSTT commands instructs the
> server to return no rows with the OPNQRYRM for the cursor or result set. A
> QRYROWSET value of zero on the CNTQRY command is invalid for non-rowset
> cursors and results in the application server generating a SYNTAXRM with a
> SYNERRCD value of '15'x (reserved value not allowed).
--
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
