>We have several reports that require data manipulation that is iterative in nature as opposed to set-based.
>My question is simple. Some of these reports seem to _require_ iterative processing, meaning SELECT-SQL simply cannot be the sole language used to gather data here. Is this reasonable?

What the other guys said is true, correct, etc. Here it is in what I consider condensed form:

Yes, you can do almost anything with SQL-SELECT if you struggle with it hard enough.

Sometimes struggling with it hard enough isn't sensible.

There are some data processing algorithms which just make more sense as nested (or especially sequential) CURSOR-filling loops in the old xBase style.

But I love SQL-SELECT, and I usually try to figure out a way to do ANY table-processing into another table (e.g. report pre-processing) with a SQL-SELECT first, and it's usually the most efficient way (in length of code and processing time both) to do it. But there are times when I've stuggled with difficult join/inclusion rules for too long where I'll sit back and look at it from another angle and decide that an old-fashioned loop or two make more sense.

As usual, the briefest answer to your question is "It depends!" :)

- Rich.