Thanks for your replies. I've already solved my problem, just creating a unique clustered index. But I haven't understood what happened yet in the 2 cases above.
As suggested by Mark, I've read Chapter 18 from Transact SQL Users Guide. In section
"Join cursor processing and data modifications", there is a citation about what happens with cursor position after a update:
"A searched or positioned update on an allpages-locked table can change the location of the row; for example, if it updates key columns of a clustered index. The cursor does not track the row; it remains positioned just before the next row at the original location. Positioned updates are not allowed until a subsequent fetch returns the next row. The updated row may be visible to the cursor a second time, if the row moves to a later position in the search order".
As stated above, the cursor position keeps the same independently if the rows change their order.
I don't know if my logic is very simplistic, but I imagine that what should happen in #Test Case 1 is (assuming the access method is a clustered index scan):
a) After the 2nd fetch, cursor position is on 2nd row:
c1 c2 c3
---- ---- ---
1 1 N
2 1 N <-- cursor position
2 2 N
b) After the update, 2nd and 3rd rows switch their positions, but cursor should keep its position (before 3rd row):
c1 c2 c3
---- ---- ---
1 1 N
2 2 N
<-- cursor position
2 1 N
c) On 3rd fetch, the 3rd row is read "again" and cursor reaches the end of table.
In relation #Test Case 2, I can't imagine how a cursor could enters a infinite loop since the cursor position shouldn't change and "apparently the row positions are the same" after the "incorrect" update.
Moreover, I still have doubts about how a field update that isn't in a clustered index can change row position in a allpages-locked table.
The main goal of my questions isn't solve the problems but get a better knowledge about some Sybase internals (and avoid similar problems in the future).
Please give me more detailed explanations about my questions and comment my analysis. Related readings about this issues are welcome.
Douglas