FIX: Bad Token or AV If Sp_cursoropen After Dropping IndexLast reviewed: June 27, 1997Article ID: Q164215  | 
	
	
 
 
The information in this article applies to:
 
 SYMPTOMSSp_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: 
 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(). 
 WORKAROUNDTo work around this problem, do any of the following: 
 STATUSMicrosoft 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 INFORMATIONSQL 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: 
 © 1998 Microsoft Corporation. All rights reserved. Terms of Use.  |