BUG: UPDATE on Cursor Without Unique Index Fails w/ Msg 16934Last reviewed: December 18, 1997Article ID: Q178298 |
The information in this article applies to:
SYMPTOMSUpdates using a positioned cursor (such as UPDATE WHERE CURRENT OF) that is declared with a join clause where ALL tables in the join do NOT have unique indexes, may cause the following error:
Msg 16934, Level 16, State 7 Optimistic concurrency check failed, the row was modified outside of this cursor.The first positioned cursor update will be successful. However, the next update (@@FETCH_STATUS is 0 after a FETCH of the next row) will fail with Msg 16934. The next FETCH after the failed update will force @@FETCH_STATUS to -1. This problem occurs even if some or one of the tables in the join have a unique index.
WORKAROUNDTo work around this problem, ensure that all tables referenced in the DECLARE CURSOR statement have a unique index.
STATUSMicrosoft has confirmed this to be a problem in SQL Server version 6.5. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available.
|
Additional query words:
© 1998 Microsoft Corporation. All rights reserved. Terms of Use. |