BUG: Cursor on Query with Aggregate Blocks with READ UNCOMMITTEDID: Q189946
|
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.
To work around this problem, use either of the following methods:
Microsoft 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.
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:
spid locktype table_id page dbname
-----------------------------------------------------------------------
11 Sh_table 1113055001 0 pubs
select object_name (<table_id>)
use pubs
go
select object_name (1113055001)
go
Additional query words:
serverside performance slow poor count(*) sum exec sp_cursoropen
resultset resultsets recordset recordsets roundtrip side roundtrip roundtrips
Keywords : SSrvLock kbbug6.50
Version : WINNT:6.5
Platform : winnt
Issue type : kbbug
Last Reviewed: April 16, 1999