Application developers have long lamented the seemingly delinquent support for passing an unbounded number of parameters to a SQL Server stored procedure. Such support has always existed, but the mechanism has never been entirely intuitive.
Observe a stored procedure defined thusly:
Create proc sp_AsManyAsYouLike as
set nocount on Select myInt * 1000 from #tempParam
go
Now I bring all of my Perl programming skills to bear:
$cmd->{ActiveConnection} = $conn;
$cmd->{CommandType} = 1;
$cmd->{CommandText} = "set nocount on Create table #tempParam (MyInt int)\n";
$cmd->{CommandText} = $cmd->{CommandText} . "Insert #tempParam Select 1\n";
$cmd->{CommandText} = $cmd->{CommandText} . "Insert #tempParam Select 2\n";
$cmd->{CommandText} = $cmd->{CommandText} . "Exec sp_AsManyAsYouLike";
$WScript->Echo($cmd->CommandText . "\n");
$RS = $cmd->Execute();
while(!$RS->EOF){
$WScript->Echo($RS->Fields(0)->value);
$RS->MoveNext;}
Which yeilds the following:
set nocount on Create table #tempParam (MyInt int)
Insert #tempParam Select 1
Insert #tempParam Select 2
Exec sp_AsManyAsYouLike
1000
2000
My example above is simplistic, but you can extend this model to pass all sorts of complex structures to a stored procedure. I don't offer this solution as a brilliant design. It is merely more palatable, and more flexible, than parsing strings with Transact SQL.