Microsoft KB Archive/170994
Article ID: 170994
Article Last Modified on 3/14/2006
- Microsoft SQL Server 6.5 Standard Edition
This article was previously published under Q170994
When updating a cursor, SQL Server generates an access violation (AV) and generates a stack trace and a dump file. From ISQL, users receive the following error:
ODBC users receive the following error and the client application typically stops responding (including the development environment, such as Visual Basic):
In Visual Basic, the AV occurs when an Edit/Update is performed against a recordset of a VIEW that contains an ANSI style INNER JOIN, or when an equi- join to a SQL Server cursor is opened and an attempt is made to update that cursor. The recordset's cursor type (KEYSET, DYNAMIC, or FORWARD_ONLY) has no effect on the failure. That is, it fails no matter what cursor type is used.
This problem does not occur with a STATIC cursor because a STATIC cursor is read-only, and the AV occurs during the attempt to update.
To work around this problem, create the view using Transact-SQL style outer joins (for example, *= or =*).
For example, use the following statements to create the view: CREATE VIEW view_TEST AS select authors.* from authors, authors_useraccess where authors.au_id *= authors_useraccess.au_id and user = authors_useraccess.usercode GO
Microsoft has confirmed this to be a problem in SQL Server 6.5. This problem has been corrected in Service Pack 5a for Microsoft SQL Server 6.5.For more information, click the following article number to view the article in the Microsoft Knowledge Base:
197177 INF: How to Obtain SQL Server 6.5 Service Pack 5a
For more information, contact your primary support provider.
The following stack trace is from the DEBUG version 6.50.0240:
***BEGIN STACK TRACE*** 0x005D1DC7 in SQLSERVR.EXE, startscan() + 0x01D7 0x004AE360 in SQLSERVR.EXE, exec_substitute() + 0x0435 0x004ACC38 in SQLSERVR.EXE, exec_eop() + 0x0493 0x004ACEA3 in SQLSERVR.EXE, exec_eop() + 0x06FE 0x004AC987 in SQLSERVR.EXE, exec_eop() + 0x01E2 0x004AC8F3 in SQLSERVR.EXE, exec_eop() + 0x014E 0x004AC400 in SQLSERVR.EXE, execute() + 0x02C0 0x005575B4 in SQLSERVR.EXE, s_execute() + 0x0C54 0x0050CC3C in SQLSERVR.EXE, sequencer() + 0x035C 0x0051EFC6 in SQLSERVR.EXE, cursorupdate() + 0x10A7 0x0051D7CF in SQLSERVR.EXE, xpcursor() + 0x05D9 0x0055AAEA in SQLSERVR.EXE, execproc() + 0x06B1 0x0055783D in SQLSERVR.EXE, s_execute() + 0x0EDD 0x0050CC3C in SQLSERVR.EXE, sequencer() + 0x035C 0x00416561 in SQLSERVR.EXE, language_exec() + 0x06D6 0x002417B6 in opends60.dll 0x00241BE0 in opends60.dll 0x00243BA2 in opends60.dll 0x002439F1 in opends60.dll 0x10219D84 in MSVCRT40.dll 0x77F04F2C in KERNEL32.dll ***END STACK TRACE***
This bug is handled by SQL Server, and a dmp file is created.
This problem happens on SQL Server builds 6.50.240 and 6.50.258. It does not happen on SQL Server builds 6.50.201, 6.50.213 and 7.00.257.
NOTE: RDO will generate the sp_cursorfetch and sp_cursor calls from the following code:
Set rs = con.OpenResultset("Select * from view_TEST", rdOpenKeyset, & _ rdConcurRowVer, rdExecDirect) rs.Edit rs!au_fname = "Gorf" rs.Update <------- here's where it will fail and lock up
Additional query words: prodsql sp sp5
Keywords: kbbug kbfix kbusage KB170994