Почему не вызвать процедуру столько раз, сколько параметров?
Типа этого:

create proc my_sp
@param int
as
...
...


а в приложении в рамках транзакции (например, через ADO Connection.BeginTrans и т.п.)
не вызвать my_sp нужное число раз?

Тем более, что у вас простейший случай. А что будет, если потребуется сделать что-то
более-менее сложное для каждого значения v?

2Perez
Об UDF можно почитать в Books Online, что поставляются вкупе с MS SQL Server.
Также есть неплохой ресурс sqlteam.com

Что касается "распарсить в процедуре":

\nCREATE FUNCTION dbo.ItemsList
(
@InputString varchar(4096),
@Separator char(1)
)
RETURNS @MyTable TABLE (MyTableID int)
AS
BEGIN
DECLARE @i int
SET @InputString = @InputString + @Separator
SET @i = CHARINDEX(@Separator, @InputString)
WHILE @i > 0
begin
INSERT INTO @MyTable (MyTableID) SELECT CAST(SUBSTRING(@InputString, 1, @i-1) AS int)
SET @InputString = RIGHT(@InputString, LEN(@InputString) - @i)
SET @i = CHARINDEX(@Separator, @InputString)
end
RETURN
END
GO

SELECT * FROM ItemsList('1,2,3',',')
GO


Ессно, предполагается, что передаются только "целые" числа, разделенные одним
символом (@Separator), причем общей длиной не более 4 кБ. Обработку ошибок
надо сделать самостоятельно.


P.S. И все-таки, парсинг строк - не самый лучший вариант решения...

а неуж то нет какой-нить готовой процедуры или функции типа как вбскрипте SPLIT?
В T-SQL нет массивов (таблицы не считаем), потому вернуть результаты будет негде, в отличие от VBScript.

и почему парсинг не лучший вариант? (это из-за того что нада обрабатывать ислючительные ситуации?)
я в том плане чтоб совсем разделить веб и данные/методы_обрабоки_данных

Это тебе кажется, что ты разделяешь. На самом деле, ты соединяешь. Посмотри сам: в процедуру передается
символ-разделитель, а он есть "часть" логики представления (presentation logic). А надо бы, чтобы в проц.
шли независимые от интерфейсов данные, то бишь числа, даты (во внутреннем формате, ессно), строки...
Потому все потуги передавать в SP данные в виде строк (даты, например) и далее их парсить - порочны априори.

Мне могут возразить, что в описанном мной варианте надо использовать транзакцию, лежащюю вне хранимых
процедур. Это единственный минус... Кстати, он будет и для способа, когда набор параметров передается
через (временную) таблицу.