You also can't pass an array to a stored procedure; there's no such entity
in SQL Server.
If there's a lot of data, a temp or working table is probably best. Your
client uses ADO methods to create the table (if temp), fill the table,
execute the stored procedure, then drop the table.
If there isn't much data, you can use optional parameters to your benefit.
create procedure a(
as
...
If the processing is a little more complicated than a simple insert, do
something like this instead.
create procedure a(
as
declare cntr int
select cntr=0
begin
....
end
....
end
end
You can also concatenate your columns and rows into one or more varchar
procedure parameters. Fixed width layout of the columns and rows is easiest
to parse; delimitted columns and rows are harder to parse in a stored
procedure. SQL7 accepts up to 8000 characters. Use WHILE to loop.
SUBSTRING() to get individual column values (parse). RTRIM() to trim off
padding characters.
as
begin
end
Don.
I have seen someone at least pass an array of data to a sp and use data from
that
to process info. Is that a feasable solution instead of a recordset? If
so, any
ideas on how that is done?