I would disagree with the contention that STATIC cursors should be avoided. Obviously, there are instances where this is true, and yes, this does cause the result set to be written to tempdb.

However, the author does not go on to explain what happens (or at least what my experience seems to indicate happens) with a dynamic cursor. Here's an interesting experiment I (inadvertently) tried once. I ran a dynamic cursor update loop that would update 4 records out of 10 million, and another that would update 10,000. My results? The two operations took almost the same amount of time to complete. Switching to local static cursors, performance of the 4 row update improved dramatically.

However, as is almost always the case, there is a significant time vs. space issue here. If you're tight on disk space, and the speed of the update is not an issue, then regular cursors can be your best bet (although, alternately, you might be able to work with a table variable, if you've got the memory to spare).

If you are selecting data based on unique key values, especially if those values are primary keys, and you have the space in tempdb to hold the cursor result set, use a local static cursor to find the keys.