Microsoft KB Archive/185965

= FIX: Query Cancellation May Fail If No Delay After Query =

Article ID: 185965

Article Last Modified on 3/14/2006

-

APPLIES TO


 * Microsoft SQL Server 6.5 Standard Edition

-



This article was previously published under Q185965



BUG #: 17945 (6.5)



SYMPTOMS
Under extremely narrow conditions, query cancellation can fail, causing a query to continue running on the server. During this interval the client will wait on the cancel API call. When the query completes, the server will acknowledge (ACK) the cancel to the client, which falls off the wait and continues.



WORKAROUND
You can avoid the problem by inserting an approximately 50-millisecond delay before the query cancellation.



STATUS
Microsoft has confirmed this to be a problem in SQL Server 6.5. This problem has been corrected in Service Pack 5a for Microsoft SQL Server 6.5.For more information, click the following article number to view the article in the Microsoft Knowledge Base:

197177 INF: How to Obtain SQL Server 6.5 Service Pack 5a

For more information, contact your primary support provider.



MORE INFORMATION
From an API standpoint, query cancellation is done through the ODBC calls SQLCancel or SQLFreeStmt, or the DB-Library call dbcancel.

From a user interface standpoint, query cancellation is done by certain user actions that trigger one of the above APIs. For example, pressing CTRL+C in the Isql.exe console screen while results are returning will cause dbcancel to occur.

The problem only occurs if queries are canceled immediately after sending. For example if, after sending a query with SQLExecDirect, the query is immediately canceled with SQLCancel, the problem may happen, but very infrequently. It typically occurs with less than 0.1 percent frequency.

It is unlikely that the timing window can be reproduced by a human-driven cancellation. Rather the application must do this programmatically using the above APIs.

When discussing this area, the terms cancel and attention are often used interchangeably. Also note that ACK is short for acknowledgment when used in a network or client/server context.

The problem occurs frequently with multiple connections and symmetric multiprocessing (SMP) hardware, however it can be seen under a single connection, uniprocessor environment. The problem is very timing sensitive and happens more frequently with local (unnamed) pipes than it does with a local network named pipe.

Detailed Description
The following is a detailed description of the mechanism of the problem. The client (running on a local server) sends a query and immediately cancels. The cancel results in writefile on client, followed almost immediately by readfile, waiting for ACK. The server continues running the query, and does not ACK the client, which causes the client to wait. The duration of the wait is proportional to the query running time: the bigger the table, the longer the wait. After the query completes, the ACK is sent and the client drops off of the wait.

Keywords: kbbug kbfix KB185965

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.