The information in this article applies to:
BUG #: 18074 (SQLBUG_65) SYMPTOMS
Opening a cursor on a query with an aggregate function will block other
users as it acquires a shared lock on the underlying table(s) for the
duration of the time required to open the cursor. This lock is acquired
even with TRANSACTION ISOLATION LEVEL set to READ UNCOMMITTED. The same
query executed outside of the cursor will not acquire the shared lock with
the same transaction isolation level. This happens with all cursor types,
whether the user explicitly declares and opens the cursor, or if an
application uses server-side cursors when opening result sets or record
sets.
WORKAROUND
To work around this problem, use either of the following methods:
STATUSMicrosoft has confirmed this to be a problem in SQL Server version 6.5. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available. MORE INFORMATION
The shared locks can be viewed by executing the sp_lock stored procedure
from a separate connection while the cursor is being opened. The following
is sample output:
Table_id is the object ID of the table the cursor with the aggregate function is being opened on. To find the object name, run the following query in the database listed in the dbname column:
So for this case, the syntax would be:
Additional query words:
serverside performance slow poor count(*) sum exec sp_cursoropen
Keywords : SSrvLock kbbug6.50 |
Last Reviewed: April 16, 1999 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |