use SQL server's profiler to check for blocking locks.My guess is that the first cursor still has a shared lock on the rows read and while not yet completed you open another cursor (update) which conflicts with the previous one.

What is your isolation level? try setting the isolation level for the session to READ UNCOMITTED just to check that it's a locking issue;remember this isolation level is not otherwise recommended

you are using cursor-based procedural logic;try to mix your select with the update in one query and since I see that you check the values of 2 returned columns,use a CASE clause to place your filter and do your update

or read all rows in an array,commit the select and then iterate through it in the client's memory,opening a cursor and doing your updates. However this has the drawback that your update might fail if another transaction has already changed your row in the mean time,since you take no shared/read locks