FIX: Bad Token or AV If Sp_cursoropen After Dropping Index (164215)
The information in this article applies to:
This article was previously published under Q164215 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: - 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.
- Close the cursor.
- Drop the index or constraint.
- 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.
| Modification Type: | Major | Last Reviewed: | 8/10/2006 |
|---|
| Keywords: | kb3rdparty kbbug kbfix kbHardware KB164215 |
|---|
|