• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Passing a LIST of values to stored procedure?

SoftwareEng

Senior member
Hi fellow programmers,

How can I pass a list of values, e.g. an array, to a stored proc in SQL server? The list could have just one or one hundred values. Is there a better way than building and passing one long string, and then splitting it on the server?

Thank you very much.
 
As far as I know you can not pass arrays into stored procedures in mysql, at least you couldn't last time I looked.
 
It's an old problem in stored procs, and programmers have come up with various hacks to do it. Here is a message post from Joe Celko, one of the top SQL Server gurus in the industry...

~~

Passing a list of parameters to a stored procedure can be done by putting them into a string with a separator. I like to use the traditional comma. Let's assume that you have a whole table full of such parameter lists:

CREATE TABLE InputStrings
(keycol CHAR(10) NOT NULL PRIMARY KEY,
input_string VARCHAR(255) NOT NULL);

INSERT INTO InputStrings VALUES ('first', '12,34,567,896');
INSERT INTO InputStrings VALUES ('second', '312,534,997,896');
...

This will be the table that gets the outputs, in the form of the original key column and one parameter per row.

CREATE TABLE Parmlist
(keycol CHAR(5) NOT NULL PRIMARY KEY,
parm INTEGER NOT NULL);

It makes life easier if the lists in the input strings start and end with a comma. You will also need a table called Sequence, which is a set of integers from 1 to (n).

SELECT keycol,
CAST (SUBSTRING (',' + I1.input_string + ',', MAX(S1.seq + 1),
(S2.seq - MAX(S1.seq + 1)))
AS INTEGER),
COUNT(S2.seq) AS place
FROM InputStrings AS I1, Sequence AS S1, Sequence AS S2
WHERE SUBSTRING (',' + I1.input_string + ',' , S1.seq, 1) = ','
AND SUBSTRING (',' + I1.input_string + ',' , S2.seq, 1) = ','
AND S1.seq < S2.seq
AND S2.seq <= DATALENGTH(I1.input_string) + 1
GROUP BY I1.keycol, I1.input_string, S2.seq
ORDER BY I1.keycol, I1.input_string, S2.seq

The S1 and S2 copies of Sequence are used to locate bracketing pairs of commas, and the entire set of substrings located between them is extracts and cast as integers in one non-procedural step. The trick is to be sure that the left hand comma of the bracketing pair is the closest one to the second comma. The place column tells you the relative position of the value in the input string


--CELKO--
Joe Celko, SQL Guru

~~~

And here is a link to a page with several descriptions of workarounds:

http://vyaskn.tripod.com/passi..._stored_procedures.htm

And here is a simpler way to do it using XML fragments if you are running against SQL Server 2005:

http://weblogs.asp.net/dwahlin...n-sql-server-2005.aspx
 
You can't.

Stored procedures are designed to be static, and precompiled on the server. It doesn't support AD-HOC or changing parameters like that. Those things require the SQL to be compiled, which beats the entire purpose of being a stored procedure.
 
Originally posted by: brandonb
You can't.

Stored procedures are designed to be static, and precompiled on the server. It doesn't support AD-HOC or changing parameters like that. Those things require the SQL to be compiled, which beats the entire purpose of being a stored procedure.

Absolutely true. You lose the execution advantages of precompiled statements. I wouldn't say that is the "entire purpose" of a stored procedure, though. Encapsulation and modularity are still important, and in general the advantages stored procedures have over embedded SQL due to precompilation have been diminishing. As far as I know, SQL Server 2005 will also precompile and cache embedded SQL statements now. If that's true then one of the primary remaining advantages of stored procs is modularity.
 
Either pass in an XMLDocument (NText field) and use OPENXML etc or pass in a string and use a function to split it up.
 
Heh, I just realized he said SQL Server not mysql. Damn me for commenting before having any coffee 🙁
 
if its a list of values, you should be able to process them individually...

it will probably be slower, but it would be better programming practice to pass in each value one by one within a loop.
 
What kind of objects are you dealing with? Are these simple string values in an array?
If so, you can always use SQLCLR. Imagination is your limit! Just be cautious of the performance though - it all depends on what you're trying to achieve.
 
Thank you all for your help!

It sucks that there is no "parameter array" data type for stored procedures... Maybe SQL Server 2005/08 is better in this regard.
 
Originally posted by: SoftwareEng
Thank you all for your help!

It sucks that there is no "parameter array" data type for stored procedures... Maybe SQL Server 2005/08 is better in this regard.

2005 gives you the XML capability that can be useful for this. Other than that it doesn't add any native support for array or list parameters. Not sure about the next version.
 
Back
Top