Consider the table SAMPLE:
id integer
name nvarchar(10)
There is a stored proc called myproc. It takes only one paramater ( which is id)
Given a name as parameter, find all rows with the name = @nameparameter and pass all those ids
to myproc
eg:
sample->
1 mark
2 mark
3 stu
41 mark
When mark is passed, 1 ,2 and 41 are to be passed to myproc individually.
i.e. the following should happen:
execute myproc 1
execute myproc 2
execute myproc 41
I can’t touch myproc nor see its content. I just have to pass the values to it.
If you must iterate(*), use the construct designed to do it – the cursor. Much maligned, but if it most clearly expresses your intentions, I say use it:
(*) This answer has received a few upvotes recently, but I feel I ought to incorporate my original comment here also, and add some general advice:
In SQL, you should generally seek a set-based solution. The entire language is oriented around set-based solutions, and (in turn) the optimizer is oriented around making set-based solutions work well. In further turn, the tools that we have available for tuning the optimizer is also set-oriented – e.g. applying indexes to tables.
There are a few situations where iteration is the best approach. These are few are far between, and may be likened to Jackson’s rules on optimization – don’t do it – and (for experts only) don’t do it yet.
You’re far better served to first try to formulate what you want in terms of the set of all rows to be affected – what is the overall change to be achieved? – and then try to formulate a query that encapsulates that goal. Only if the query produced by doing so is not performing adequately (or there’s some other component that is unable to do anything other than deal with each row individually) should you consider iteration.