Stored procedures with recordset as parameter:

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

namasi_navaretnam, could you explain
"To make  the proc compile just create the temptable outside the proc"

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

>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.

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.

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.

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

I'm not quite sure if you can pass a table (variable). You can however pass a cursor.

That is interesting CJ_S. Would you post a cursor example if you have one?

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.

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

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.

I agree robertbaker.

Consider as an alternative to pass your resultset as an XML document.  But I suspect you need to rethink your approach.

Anthony