FIX: Update View with Inner Join from Cursor Causes AV

Retired KB Content Disclaimer

View products that this article applies to.

This article was previously published under Q170994

Expand all | Collapse all

SYMPTOMS

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:

DB-Library: Possible network error: Error in sending out-of-band data to SQL Server.
Net-Library error 232: ConnectionWrite (GetOverLappedResult()).

ODBC users receive the following error and the client application typically stops responding (including the development environment, such as Visual Basic):

[Microsoft][ODBC SQL Server Driver]Protocol error in TDS stream

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.

Back to the top

WORKAROUND

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

Back to the top

STATUS

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 (http://support.microsoft.com/kb/197177/ ) INF: How to Obtain SQL Server 6.5 Service Pack 5a

For more information, contact your primary support provider.

Back to the top

MORE INFORMATION

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

Back to the top

APPLIES TO

Microsoft SQL Server 6.5 Standard Edition

Back to the top

kbbug kbfix kbusage KB170994

Back to the top

Retired KB Content Disclaimer

This article was written about products for which Microsoft no longer offers support. Therefore, this article is offered "as is" and will no longer be updated.

Back to the top