FIX: Bad Token or AV If Sp_cursoropen After Dropping Index

Last reviewed: June 27, 1997
Article ID: Q164215
The information in this article applies to:
  • Microsoft SQL Server, version 6.5
BUG #: 16556 (6.5)

SYMPTOMS

Sp_cursoropen generates an access violation (AV) in xpcursordeclare (on a checked server) or breaks the connection (on a retail server) if you do all of the following:

  1. Open an extended KEYSET_DRIVEN or INSENSITIVE extended cursor on a stored procedure that references a table containing a unique clustered index, non-clustered index, or primary key (PK) constraint.

  2. Close the cursor.

  3. Drop the index or constraint.

  4. Open the cursor again.

The symptom of the broken connection is usually a "bad token" message returned to the client. Slight variations of this may cause an AV in cursornewrow on a checked (or debug) server.

An extended KEYSET_DRIVEN cursor is exposed at the DB-Library API layer as CUR_KEYSET in dbcursoropen() and at the ODBC API layer as SQL_CURSOR_KEYSET_DRIVEN in SQLSetStmtOption(). An extended INSENSITIVE cursor is exposed at the DB-Library layer as CUR_INSENSITIVE in dbcursoropen(), and at the ODBC API layer as SQL_CURSOR_STATIC in SQLSetStmtOption().

WORKAROUND

To work around this problem, do any of the following:

  • Use a different cursor type.
  • Use trace flag -T7502 to "Disable caching cursor plans in procedure cache."
  • Create the stored procedure WITH RECOMPILE.
  • Drop and re-create the stored procedure after making a table schema change.

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.

MORE INFORMATION

SQL Server supports two different server-side cursor interfaces. One is ANSI SQL cursors, which are exposed through Transact-SQL statements such as DECLARE, FETCH, and so on. The other cursor interface is an extended cursor interface that is accessed through the DB-Library and ODBC APIs. The sp_cursor extended cursor statements are emitted by the DB-Library or ODBC layers in response to certain DB-Library or ODBC API calls. Higher- level interfaces such as Remote Data Objects (RDO) will often encapsulate these API-level calls, so you would need to run a trace utility such as SQL Trace to verify the sp_cursor call being made.

For more information on cursors and concurrency modes, see the on-line documentation and the following article in the Microsoft Knowledge Base:

   ARTICLE-ID: Q156489
   TITLE     : Overview of SQL Server, ODBC, and DB-Library Cursors


Additional query words:
Keywords : kb3rdparty kbhw SSrvDB_Lib SSrvGen kbbug6.5
Version : 6.5
Platform : WINDOWS
Issue type : kbbug
Resolution Type : kbfix


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: June 27, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.