Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2000 Forums
 Transact-SQL (2000)
 Array parameters ?

Author  Topic 

Utpal
Posting Yak Master

179 Posts

Posted - 2002-03-03 : 00:24:28
Hi everybody,

Can arrays be passed as parameters to stored procedures ? Or is there any other way to emulate that ?


MichaelP
Jedi Yak

2489 Posts

Posted - 2002-03-03 : 00:41:33
You could pass a delimited string and pick out the parts you want

You could also use dynamic SQL. Do a search on this site for dyanmic SQL.

Michael

Go to Top of Page

MichaelP
Jedi Yak

2489 Posts

Posted - 2002-03-03 : 00:41:39
You could pass a delimited string and pick out the parts you want

You could also use dynamic SQL. Do a search on this site for dyanmic SQL.

Michael

Go to Top of Page

MichaelP
Jedi Yak

2489 Posts

Posted - 2002-03-03 : 00:41:43
You could pass a delimited string and pick out the parts you want

You could also use dynamic SQL. Do a search on this site for dyanmic SQL.

Michael

Go to Top of Page

robvolk
Most Valuable Yak

15732 Posts

Posted - 2002-03-03 : 06:23:46
graz has an article on how to do this:

http://www.sqlteam.com/item.asp?ItemID=637

Go to Top of Page

Utpal
Posting Yak Master

179 Posts

Posted - 2002-03-04 : 05:48:13
Thanks a lot !

Go to Top of Page

Utpal
Posting Yak Master

179 Posts

Posted - 2002-03-04 : 07:18:59
Graz's technique would not allow to pass an unlimited number of elements to the stored procedure through a single string, because the length of the parameter has to be specified e.g. Array_Name VarChar(1000). If a huge parameter length is specified e.g. VarChar(1000000000000), would that consume a lot of memory even if the length of the string passed is less ?


Go to Top of Page

robvolk
Most Valuable Yak

15732 Posts

Posted - 2002-03-04 : 07:24:26
The maximum length of a string that can be passed is 8000 characters. If you need to pass more use multiple varchar(8000) parameters.

I don't know how much data you're trying to pass to the stored procedure, but it can accept up to 1024 parameters of 8000 characters each, that's 8MB of data. While this is a relatively minor amount of memory for SQL Server to handle, it's an excessive amount to pass to a stored procedure. If you feel you need to pass more than 200K of data you should reconsider your design.

Edited by - robvolk on 03/04/2002 07:25:28
Go to Top of Page

davidpardoe
Constraint Violating Yak Guru

324 Posts

Posted - 2002-03-04 : 08:03:40
Way to go MichaelP on the old get the posts up high thing

============
The Dabbler!
Go to Top of Page

Utpal
Posting Yak Master

179 Posts

Posted - 2002-03-05 : 05:12:45
Thanks a lot Robvolk !
Using multiple parameters would be difficult. I need to pass arrays for each of my columns in a Purchase Order detail block. I'll have to think of how to organize and use the parameters in the stored procedure. I'll give it a try.


Go to Top of Page

robvolk
Most Valuable Yak

15732 Posts

Posted - 2002-03-05 : 14:57:01
There's an idea here you might want to try:

http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=12538

It uses multiple parameters of fixed-length values and splits them out for INSERT. Each column would be passed as a parameter (10 columns = 10 parameters). I doubt you have 1024 columns to insert (!) so this should work fine. You need to modify this though if you are going to insert Nulls into the table.

Unless you are INSERTing several hundred rows from the detail area, or have some incredibly complicated process, there's nothing wrong with calling the SP multiple times to insert the data. I wrote an ASP page a while back that would call the SP for each row inserted; it tested fine for 500 rows, and was only a little slow for 1,000 row inserts. This was far more than would ever actually be done in one order. Not saying it's the most efficient way, but unless you're seeing performance problems now there's no point making the process more complicated.

Go to Top of Page

Utpal
Posting Yak Master

179 Posts

Posted - 2002-03-06 : 04:42:49
The sequence table concept is a genius of an idea ! It took me quite some time to grasp it. I could use that concept for not only implementing the multiple insert SP but also for other things like a SP to execute a multiple keyword search on a table and maybe a lot others.

However, I don't want to call the SP multiple times if the number of inserts exceed 8000/Len(value to be inserted), because I want to execute the inserts as a single transaction within a BEGIN TRAN and COMMIT TRAN. This is because in my case I am saving a new Purchase Order. I want to save the Purchase Order header and item details as a single transaction, so that either everything in the Purchase Order is saved, or if something goes wrong, nothing is saved (ROLLBACK occurs). Am I thinking right ?



Edited by - Utpal on 03/06/2002 04:47:02
Go to Top of Page

robvolk
Most Valuable Yak

15732 Posts

Posted - 2002-03-06 : 07:03:37
Yes, that's correct, and keeping it in a transaction is a good idea and makes sense. As long as you can make it work without rewriting everything or otherwise killing yourself!

Go to Top of Page

Utpal
Posting Yak Master

179 Posts

Posted - 2002-03-07 : 04:50:21
Thanks !

Go to Top of Page
   

- Advertisement -