Come on guys (and gals) - this is obviously a multi-part series, and this part was subtitled 'Part 1: An introduction'.

And at the end, the author states 'coming up in,part 2 ....'

So stop saying it is lacking in content! R Barry Young is just setting the scene for what I imagine is going to be a very informative discussion. And if you take offense at his analogy, I'm sure it is meant light-heartedly.

For all those of you who have a cursor based solution, and have tried to make it set-based only to discover that it runs slower, stay tuned to this discussion. You might learn a few tricks. Often an approach to replacing cursors with set-based solutions is flawed from the beginning as the mindset is still in row-by-row mode, and so you try to write SQL that maps onto your current solution, but is implemented using non-cursor TSQL. That's not a slur on your skills, it's just very difficult to break away from the 'answer' to a problem when you already have one that works!

Plus I guess some people here on the cursor side of the 'war' (not my description), will be naturally biased, and will be able to tells us all tales of woe where the attempt to replace the cursor with set-based has sent the query spiralling out of control. Ever stop to think you might have made an error?

Once the series is complete, if you still can't replace your cursors with something that runs faster without them, post it here. There's plenty of people who will gladly help - and no - they wont berate you for using them in the first place! They just be happy that they helped make your code run faster, and helped you learn some ways of avoiding cursors.

Kev