Knowledge Base

FIX: Sp_Cursor Positioned Update Causes Access Violation

Article ID: 161645

Article Last Modified on 10/3/2003


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.

Keywords: kbbug kbfix kbusage KB161645