Jeremy,

There may be some things in your SQL that we could look at that might speed things up. But aside from that, speed is not the only problem with CURSORS; they can also have serious memory problems associated with them that a SET-based solution usually doesn't. That said, there ARE times when a cursor will run faster, and there ARE times when a set-based solution will run faster. A lot of it is about predicting the future, as well (I know it sounds corny). If you know ahead of time that the procedure that you just implemented with a cursor will be run every minute on a production system with thousands of users, you're heading for trouble. But if the process is one-time run, or something run off-hours or on small data sets, CURSORS generally won't present a problem. That said, I have been bitten numerous times by cursors that have been implemented in procedures that weren't intended to be run all the time, but "it just turned out that they do"...If you want to post some code, we'll take a look...