Column Count from Stored Procedure

[Rolando Barberis]

I am trying to determine the number of columns that are returned from
a stored procedure using TSQL. I have a situation where users will be
creating their own procedures of which I need to call and place those
results in a temp table. I will not be able to modify those users
procedures. I figure if I have the number of columns I can dynamically
create a temp table with the same number of columns, at which point I
can then perform an INSERT INTO #TempTableCreat edDynamically EXEC
@UserProcCalled . With that said, does anyone have any idea how to
determine the number of rows that an SP will return in TSQL?

Thanks!

[Simon Hayes]

Re: Column Count from Stored Procedure

rolandobarberis @hotmail.com (Rolando Barberis) wrote in message news:<ca3f9ee4. 0405051740.7e09 0c11@posting.go ogle.com>...[color=blue]
> I am trying to determine the number of columns that are returned from
> a stored procedure using TSQL. I have a situation where users will be
> creating their own procedures of which I need to call and place those
> results in a temp table. I will not be able to modify those users
> procedures. I figure if I have the number of columns I can dynamically
> create a temp table with the same number of columns, at which point I
> can then perform an INSERT INTO #TempTableCreat edDynamically EXEC
> @UserProcCalled . With that said, does anyone have any idea how to
> determine the number of rows that an SP will return in TSQL?
>
> Thanks![/color]

If you really need to do this, the easiest way would be to do it on
the client side - for example, retrieve an ADO RecordSet, then use the
RecordSet metadata to create a table.

However, there are some issues with this general approach - if you
don't know the format of the result set in advance, then it's
difficult to do anything meaningful with it. You can't write SQL code
to process the temp table, because you don't know anything about the
number of columns, the data types, the row count (you might want to
use paging for a large result set, for example) etc. And this is in
addition to the obvious issues (security, performance, maintenance)
which may arise from allowing users to create their own code in the
database.

But since you don't give any detailed information about your goals or
your environment, it's possible that you do have good reasons for
looking at this solution. If you can give more information about what
you're trying to do, though, someone may have an alternative idea to
propose.

Simon

[Erland Sommarskog]

Re: Column Count from Stored Procedure

Rolando Barberis (rolandobarberi s@hotmail.com) writes:[color=blue]
> I am trying to determine the number of columns that are returned from
> a stored procedure using TSQL. I have a situation where users will be
> creating their own procedures of which I need to call and place those
> results in a temp table. I will not be able to modify those users
> procedures. I figure if I have the number of columns I can dynamically
> create a temp table with the same number of columns, at which point I
> can then perform an INSERT INTO #TempTableCreat edDynamically EXEC
> @UserProcCalled . With that said, does anyone have any idea how to
> determine the number of rows that an SP will return in TSQL?[/color]

This is a dead end. There is no way you can do this in SQL only. As Simon
says, you need to go client-side and deal with the the procedures there.

Not even client-side there is any good way to determine the number of
columns without running the procedure. In some contexts, ADO uses
SET FMTONLY ON which causes SQL Server to only sift through the statements
without executing them, but still return information about the result
sets. But there are several unexpected things that can happen with SET
FMTONLY ON, so in my opinion it's useless.

Then again, once you are client-side, it is not problem to run the
procedures. SQL Server will return information about the result sets,
and you will get recordsets, data tables or whatever depending on
which client library you use. (My personal preference is for ADO .Net.)

--
Erland Sommarskog, SQL Server MVP, sommar@algonet. se

Books Online for SQL Server SP3 at

http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp