46

Possible Duplicate:
Retrieve column definition for stored procedure result set

I use the following SQL to get column names and types for a table or view:

DECLARE @viewname varchar (250);

select a.name as colname,b.name as typename 
from syscolumns a, systypes b -- GAH!
where a.id = object_id(@viewname) 
and a.xtype=b.xtype 
and b.name <> 'sysname'

How do I do something similar for the output columns of a stored procedure?

Community
  • 1
  • 1
Wang Wei
  • 573
  • 1
  • 5
  • 10

2 Answers2

105

[I just realized I've answered this question before]

Doing this for a stored procedure is a lot more complicated than it is for a view or table. One of the problems is that a stored procedure can have multiple different code paths depending on input parameters and even things you can't control like server state, time of day, etc. So for example what you would expect to see as the output for this stored procedure? What if there are multiple resultsets regardless of conditionals?

CREATE PROCEDURE dbo.foo
  @bar INT
AS
BEGIN
  SET NOCOUNT ON;

  IF @bar = 1
    SELECT a, b, c FROM dbo.blat;
  ELSE
    SELECT d, e, f, g, h FROM dbo.splunge;
END
GO

If your stored procedure does not have code paths and you are confident that you will always see the same result set (and can determine in advance what values should be supplied if a stored procedure has non-optional parameters), let's take a simple example:

CREATE PROCEDURE dbo.bar
AS
BEGIN
  SET NOCOUNT ON;

  SELECT a = 'a', b = 1, c = GETDATE();
END
GO

SQL Server 2012+

There are some new functions introduced in SQL Server 2012 that make metadata discovery much easier. For the above procedure we can do the following:

SELECT [column] = name, system_type_name
FROM sys.dm_exec_describe_first_result_set_for_object
(
  OBJECT_ID('dbo.bar'), 
  NULL
);

Among other things this actually provides precision and scale and resolves alias types for us. For the above procedure this yields:

column   system_type_name
------   ----------------
a        varchar(1)
b        int
c        datetime

Not much difference visually but when you start getting into all the different data types with various precision and scale you'll appreciate the extra work this function does for you.

The downside: So far (through SQL Server 2022), this only works for the first resultset (as the name of the function implies).

FMTONLY

On older versions, one way is to do something like this:

SET FMTONLY ON;
GO
EXEC dbo.bar;

This will give you an empty resultset and your client application can take a look at the properties of that resultset to determine column names and data types.

Now, there are a lot of problems with SET FMTONLY ON; that I won't go into here, but at the very least it should be noted that this command is deprecated - for good reason. Also be careful to SET FMTONLY OFF; when you're done, or you'll wonder why you create a stored procedure successfully but then can't execute it. And no, I'm not warning you about that because it just happened to me. Honest. :-)

OPENQUERY

By creating a loopback linked server, you can then use tools like OPENQUERY to execute a stored procedure but return a composable resultset (well, please accept that as an extremely loose definition) that you can inspect. First create a loopback server (this assumes a local instance named FOO):

USE master;
GO
EXEC sp_addlinkedserver @server = N'.\FOO', @srvproduct=N'SQL Server'
GO
EXEC sp_serveroption @server=N'.\FOO', @optname=N'data access', 
  @optvalue=N'true';

Now we can take the procedure above and feed it into a query like this:

SELECT * INTO #t 
FROM OPENQUERY([.\FOO], 'EXEC dbname.dbo.bar;')
WHERE 1 = 0;

SELECT c.name, t.name
FROM tempdb.sys.columns AS c
INNER JOIN sys.types AS t
ON c.system_type_id = t.system_type_id
WHERE c.[object_id] = OBJECT_ID('tempdb..#t');

This ignores alias types (formerly known as user-defined data types) and also may show two rows for columns defined as, for example, sysname. But from the above it produces:

name   name
----   --------
b      int
c      datetime
a      varchar

Obviously there is more work to do here - varchar doesn't show length, and you'll have to get precision / scale for other types such as datetime2, time and decimal. But that's a start.

Aaron Bertrand
  • 272,866
  • 37
  • 466
  • 490
  • 2
    Thanks, this was a well written answer. I was trying to use your last solution ("SQL Server 2012") but there are several factors that prevent it from working. If you show the actual execution plan it will not work. It also seems to not work if you wrap it in your own function. SQL Prompt says the signature is `RETURN SELECT * FROM OPENROWSET(TABLE DMF_SP_DESCRIBE_FIRST_RESULT_SET_OBJECT, @object_id, @browse_information_mode)` but that doesn't seem to execute. The only way I could get it to work was to run it directly in a query window with no actual execution plan. – Adam Plocher Mar 23 '14 at 02:20
  • 3
    I ended up putting it in a Sproc, and it seems to work, but another factor that will prevent it from working is if your result is from a `#TEMP` table – Adam Plocher Mar 23 '14 at 05:53
  • 4
    Your SQL Server 2012 answer is clean, easy, and works at least for simple stored procedures. – Mark Meuer Nov 10 '15 at 17:14
  • 1
    You can also add `is_nullable` to the SELECT which is useful if you're using this to map to .NET types i.e., `Guid?` or `int?` – Didaxis Jun 23 '16 at 15:58
  • 1
    SQL server 2012 query doesnt work for me – Mike Jul 26 '17 at 12:59
  • @Mike what does "doesn't work" mean? What does your procedure look like? What result are you getting? What result were you expecting? Did you read the final sentence in the answer? – Aaron Bertrand Jul 26 '17 at 14:34
  • Does anyone know how to get the results set schema for a stored procedure which contains dynamic SQL on SQL 2014? We have a generic method we use to interrogate SPs across all our databases, and this no longer works on SQL 2012 and above - the OPENQUERY and 2012 methods above both complain about the dynamic SQL in the stored procedure. Unfortunately we have hundreds, if not thousands, of SPs so we can't really back through them and add the WITH RESULT SET to them. Is there another method available in 2014 which works with dynamic SQL in an SP? – Paul F Aug 08 '17 at 10:48
  • 1
    The 2012 solution doesnt work (returns NULL) if the sproc uses a temp table, works for CTEs/Table variables. – Sajjan Sarkar Nov 08 '17 at 13:32
  • 1
    @SajjanSarkar Yes, that's true, and if you look at the output of the function, you'll see one of the columns actually tells you #temp tables are not supported. – Aaron Bertrand Nov 08 '17 at 15:48
2

Are you trying to return all the stored procedures and all of their parameters? Something like this should work for that.

select * from information_schema.parameters

If you need to get the columns returned from a stored procedure, take a look here:

Get column names/types returned from a stored procedure

Community
  • 1
  • 1
sgeddes
  • 62,311
  • 6
  • 61
  • 83
  • thank you for this. This is an awesome query. I've never seen this and it's such a wealth of information! @sgeddes – Mike Jul 26 '17 at 13:00
  • 2
    Except this only lists the parameters not the columns. select * from information_schema.columns (lists off the column info which is awesome!) @sgeddes – Mike Jul 26 '17 at 13:13