Stored procedures with recordset as parameter:

I have a stored procedure that is calculating prices on products.

I would like to call that stored procedure from other stored procedures,
with a recordset of products as parameter.

I know that you can't do that in sql server.

Therefore I'm thinking of letting the first stored procedure
insert the productid's together with an unique id into a table
and then call the price procedure with that unique id as parameter.

I would like to have comments on this approach.
LVL 3
olaAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

robertjbarkerCommented:
You could modify the procedure that needs the recordset to call the procedure providing the record set and put the results in a temporary table.  Something like:

create procedure userecordset as

begin
create table #recordset
(col1 int, col2 int, col3 int)

insert #recordset
exec providerecorset

-- do something with #recordset

drop table #recordset
return
end
go
0
namasi_navaretnamCommented:
You cannot pass table or cursor as input parameter.

You can create and populate a temp table in one proc (Proc1) to calculate prices and access the the same temp table in other procs if called with the same transaction. To make  the proc compile just create the temptable outside the proc

create table #temptable
(
col1 int,
col2 int
)

go

Create Proc1 as
BEGIN
Insert #temptable
select col1, col2 from MyTable
End
go

Create Proc2
as
BEGIN
  select * from #temptable
END

go
/*temptable is populated in this proc. In you case you will populate  temptabel with prices*/
exec proc1
/* you access the same temptable in proc2 */
exec proc2
go


HTH

Namasi

0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
olaAuthor Commented:
namasi_navaretnam, could you explain
"To make  the proc compile just create the temptable outside the proc"

0
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

olaAuthor Commented:
Would it be possible to use a table variable instead of a temporary table?
0
namasi_navaretnamCommented:
>namasi_navaretnam, could you explain
> "To make  the proc compile just create the temptable outside the proc"

I said that because the second proc may complain about not finding the object #temptable when compiling as #temptable is created in Proc1.

Here is a complete example that I ran in Query Analyzer

STEP 1) Create Proc 1
drop Procedure Proc1
go

Create Procedure Proc1
as
BEGIN

create table #temptable
( col1 int,
  col2 int
)

Insert into #TempTable
select 1, 2

End
go

2) Step 2 - Create Proc2 to acccess #temptable. Notice that #temptable is create outside Proc2. This is just done to make Proc2 compile.

create table #temptable
( col1 int,
  col2 int
)
go

drop procedure Proc2
go

create procedure  Proc2
AS
BEGIN
select * from #temptable
END
go

drop table #temptable
go


Step 3) Execute Proc1 and Proc2. You can see that #temptable can be accessed within Proc2

exec Proc1
exec Proc2
go

>Would it be possible to use a table variable instead of a temporary table?

No it not possible to use table variable.

Namasi.

0
robertjbarkerCommented:
Basically all these solutions avoid passing the recordset in and out of the server.  It is easier to process everything in one place - the server.

So all this is pointed at selecting the records and then processing them without leaving the server.  And it may be even better if you go one step further; just have a single procedure that does everything, so you don't even have to pass things from procedure to procedure.
0
olaAuthor Commented:
robertjbarker, I'm considering that as well.

The downside with that is that I have about 10 stored procedures where I would like use the price logic. Then I would have to place this logic in 10 procedures.





0
robertjbarkerCommented:
I guess I should take a different point of view than my first suggestion.  I think what you want to do is, within each of your 10 procedures, create a temporary table, populate the table, then call the pricing procedure to process the records in the temporary table.

drop procedure putout
go
create procedure putout as
declare @count int
declare @col1 int
declare @col2 int
declare @col3 int
declare @str varchar(50)
select @count = count(*), @col1=max(col1), @col2=max(col2), @col3=max(col3) from #recordset
set @str = cast(@count as varchar(10)) + ' ' +
           cast(@col1 as varchar(10)) + ' ' +
           cast(@col2 as varchar(10)) + ' ' +
           cast(@col3 as varchar(10)) + ' '
print @str
return
go

drop procedure userecordset
go
create procedure userecordset (@val as int)  as

begin
create table #recordset
(col1 int, col2 int, col3 int)

insert #recordset (col1,col2,col3) values (@val,@val,@val)
exec putout

--drop table #recordset -- this is commented out for testing.
return
end
go

exec userecordset 1
exec userecordset 2
exec userecordset 3
exec putout  -- expect an error here.
exec userecordset 4
0
CJ_SCommented:
I'm not quite sure if you can pass a table (variable). You can however pass a cursor.
0
namasi_navaretnamCommented:
That is interesting CJ_S. Would you post a cursor example if you have one?
0
CJ_SCommented:
Haven't done any sp's with CURSORs but this is what SQL Server help says:


All data types, including text, ntext and image, can be used as a parameter for a stored procedure. However, the cursor data type can be used only on OUTPUT parameters. When you specify a data type of cursor, the VARYING and OUTPUT keywords must also be specified. For more information about SQL Server - supplied data types and their syntax, see Data Types.
0
namasi_navaretnamCommented:
I was able to get this example from help file. Thanks CJ_S. Ola can look into using cursor option as well.

USE pubs
GO
/* Create a procedure with a cursor output parameter. */
CREATE PROCEDURE OpenCrsr @OutCrsr CURSOR VARYING OUTPUT AS

SET @OutCrsr = CURSOR FOR
SELECT au_lname
FROM authors
WHERE au_lname LIKE 'S%'

OPEN @OutCrsr
GO

/* Allocate a cursor variable. */
DECLARE @CrsrVar CURSOR

/* Execute the procedure created earlier to fill
  the variable. */
EXEC OpenCrsr @OutCrsr = @CrsrVar OUTPUT

/* Use the variable to fetch the rows from the cursor. */
FETCH NEXT FROM @CrsrVar
WHILE (@@FETCH_STATUS <> -1)
BEGIN
   FETCH NEXT FROM @CrsrVar
END

CLOSE @CrsrVar

DEALLOCATE @CrsrVar
GO

0
robertjbarkerCommented:
I believe you can pass a cursor as an OUTPUT only.  I think Ola wants to pass something TO a pricing procedure.  So the cursor idea would have the same problem as my original suggestion.
0
namasi_navaretnamCommented:
I agree robertbaker.
0
Anthony PerkinsCommented:
Consider as an alternative to pass your resultset as an XML document.  But I suspect you need to rethink your approach.

Anthony

0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft SQL Server

From novice to tech pro — start learning today.