dm_exec_describe_first_result_set_for_object for multiple result sets

Question

Does a procedure exist to return metadata for all result sets in a stored procedure?

Something like sys.dm_exec_describe_first_result_set_for_object, but for all result sets?

Eventually, I will want to discover the metadata for every result set in every stored procedure in the database. For now, I would settle for just the result sets that sys.dm_exec_describe_first_result_set_for_object cannot describe. That is, the 2nd, 3rd, and Nth result sets.

Looking at using SQLCLR to do this now:

How to save results of a procedure with more than one result set
tSQLt - DB Unit Testing for SQL Server - ResultSetFilter.cs

Answer 1

Does a procedure exist to return metadata for all result sets in a stored procedure?

No and Yes.

No

There is no pure T-SQL means of accessing more than the first result set. Even OPENROWSET and OPENQUERY have the same limitation:

Although the query might return multiple result sets, OPEN(ROWSET|QUERY) returns only the first one.

For the record, I am neither saying nor implying that there is any common technical reason for this limitation. I am just pointing out that the limitation is not confined to sp_describe_first_result_set, sys.dm_exec_describe_first_result_set, and sys.dm_exec_describe_first_result_set_for_object.

Yes

The only way to capture info -- result set meta-data and even the results -- for result sets 2 - n is via application code. You would first execute the queries / stored procedure(s) by using SqlCommand.ExecuteReader(CommandBehavior) with a CommandBehavior of KeyInfo. Then, you can get the result set meta-data using the SqlDataReader.GetSchemaTable method, and calling the SqlDataReader.NextResult method to cycle through the result sets. Just keep in mind that while doing this via app code does not have the limitations of not working with Dynamic SQL and temporary tables, it does actually run the SQL code, and if you have DML statements and only want the result set meta-data without causing any data changes, then you will have to wrap the SQL you are testing in a BEGIN TRAN / ROLLBACK TRAN.

The type of application can be a regular Windows App, Console App, Web App, etc, or it can even be a SQLCLR function / stored procedure.

With regards to doing this via SQLCLR, a stored procedure already exists that does what is described here. It is called DB_DescribeResultSets and is part of the SQL# library (which I am the author of, and while there is a Free version, DB_DescribeResultSets is only available in the Full version).