Article ID: 197462
Article Last Modified on 10/15/2002
APPLIES TO
- Microsoft SQL Server 7.0 Standard Edition
This article was previously published under Q197462
BUG #: 53342 (SQLBUG_70)
SYMPTOMS
Positioned updates on a cursor may experience non-linear performance degradation as the number of rows affected by the cursor increases. This will occur either if the cursor is opened using ANSI syntax and updated using the WHERE CURRENT OF syntax, or if the cursor is opened and updated through an application making DB-Library, ODBC, or OLE DB calls.
Note that this will only occur if the table does not have a primary key or unique index.
WORKAROUND
To work around this problem, create a primary key or unique index on the table. Performance should scale roughly linearly with the number of rows affected by the cursor.
STATUS
Microsoft has confirmed this to be a problem in SQL Server version 7.0.
MORE INFORMATION
The primary key or unique index described in the WORKAROUND section of this article does not need to be (although it may be) on any of the columns the cursor is opened on or the column(s) being updated. Any column(s) that will uniquely identify each row is a valid choice for a primary key or unique index.
If the table can not be uniquely identified by any combination of the columns that currently exist in the table, consider adding an ID column to the table. If you do not have a meaningful value for an ID column, you can use an identity, timestamp or GUID (with a default using the newid() function) column to automatically generate IDs. Having each row be identifiably unique is a fundamental concept of any relational database and will also benefit areas other than cursor performance.
Additional query words: PK hang slows down sp_cursoropen sp_cursor oledb lib autogenerate
Keywords: kbbug kbpending KB197462
