FIX: Query Cancellation May Fail If No Delay After Query

ID: Q185965

The information in this article applies to:

Microsoft SQL Server version 6.5

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 version 6.5. This problem has been corrected in U.S. Service Pack 5a for Microsoft SQL Server version 6.5. For information about downloading and installing the latest SQL Server Service Pack, see http://support.microsoft.com/support/sql/.

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.

Additional query words:

Keywords : kbbug6.50 kbfix6.50.SP5
Version : winnt:6.5
Platform : winnt
Issue type : kbbug