FIX: Sp_Cursor Positioned Update Causes Access Violation (161645)
The information in this article applies to:
This article was previously published under Q161645
BUG #: 16439 (6.5)
SYMPTOMS
Under rare conditions, an sp_cursor positioned update may cause a handled
access violation (AV). This can usually be identified by the "sp_cursor" in
the input buffer following the errorlog stack trace. The sp_cursor command
is typically sent by DB-Library or the ODBC Microsoft SQL Server driver in
response to certain DB-Library or ODBC calls.
The problem conditions require opening multiple cursors with a certain
sequence of differing concurrency options on a stored procedure, such that
the cached access plan of a previous cursor is reused by a subsequent
cursor with a different concurrency option. The cached plan must be that of
a read-only keyset-driven cursor; the stored procedure must reference a
table containing a timestamp column; the subsequent cursor must be non-read-
only; and a positioned update must be done.
WORKAROUND
To work around this problem, do any of the following:
- Use trace flag -T7502 to disable caching of extended cursor access plans.
- Create the stored procedure on which the cursor is declared using the
WITH RECOMPILE keyword.
- Change to a different sequence of cursor operations, such that cursors
are not opened with differing concurrency modes on a given object.
STATUS
Microsoft has confirmed this to be a problem in Microsoft SQL Server
version 6.5. This problem has been corrected in U.S. Service Pack 3 for
Microsoft SQL Server version 6.5. For more information, contact your
primary support provider.
Modification Type: | Major | Last Reviewed: | 10/3/2003 |
---|
Keywords: | kbBug kbfix kbusage KB161645 |
---|
|