Sql-server – Capturing Column Names in Dynamic SQL Statement

sql serversql-server-2008-r2sql-server-2016

I'm in the process of updating some procs made for SQL 2008R2 to 2016 that are using a dynamic result set.

Assuming there is a procedure that always has exactly one result set, but the result set has a dynamic column return each time, is there a way to capture the column names at runtime in tsql without doing something janky?
I'm not worried about data types, just column names.

Thanks!

Best Answer

There's no TSQL api to examine the resultset shape of a procedure that returns multiple different resultset shapes. For normal procs you can use sp_describe_first_result_set.

If you can afford to actually run the procedure and examine the results, the least-janky solution is to use SQL CLR. In CLR you get a SqlDataReader that you can use to examine the resultset shape.

Related Solutions

Where Are Queries Against a Linked Server Processed in SQL Server?

I don't think this is empirically deterministic. My understanding is that an entire table could be brought over and processed on the calling server instead of being processed remotely on the linked server. If both servers are SQL Server 2008+ you should see scenarios like this:

SELECT x.foo FROM linked.db.dbo.x JOIN linked.db.dbo.y ON ...

And in these cases you will see that the join, filters etc. are processed on the remote server. But this should not be construed as a blanket statement! You may see slightly different remoting decisions in the plan for a slightly different scenario:

SELECT x.foo FROM localdb.dbo.x JOIN linked.db.dbo.y ON ...

These are for SQL Server 2008+ -> SQL Server 2008+ linked servers. Other linked servers (lower versions of SQL Server, other platforms altogether) may behave differently, and it may be version-dependent, it could even be specific driver-version dependent, or query-dependent (e.g. is a function used). And it of course could depend on the permissions of the linked server account - if you can't see remote statistics / cardinality for the distributed portion of the query, the local optimizer is going to be pretty blind and may not make the decision you want.

If you want to guarantee that processing occurs on the remote server before it starts streaming data across, and you have actually tried to get it work with four-part names and the plan does not try to process remotely, you can use OPENQUERY instead of explicitly referencing four-part names. Never tried that in a view, though. :-)

If you come across a case where you expect processing to occur remotely and it's not, I'm more than happy to look at the actual plan and the stats profile to help understand why (or at the very least to pass it on to some of my connections who can help).

From my own personal experience, I've found much, much, much more reliable and predictable performance by doing whatever I can to make as many queries as possible entirely local. Linked servers are useful but they certainly don't lend themselves to real-time performance. While you may think it violates DRY in some sense, I would rather pay that cost once during a mirroring session or replication and have redundant data, than potentially pay for a sub-optimal remoting decision for every single cross-server query. And if the data can be slightly delayed there are even more options for moving data across to make it available locally (log shipping, SSIS, custom).

Sql-server – sp_executesql adds statements to executed dynamic script

Prior to the sp_executesql you should see an sp_prepare statement in Profiler that would give more insight: http://msdn.microsoft.com/en-us/library/ff848808(v=sql.110).aspx

Sometimes this can be hard to find, but was made a bit easier with extended events in 2008R2 - specifically causality tracking.

http://msdn.microsoft.com/en-us/library/bb630284.aspx

Best Answer

Related Solutions

Where Are Queries Against a Linked Server Processed in SQL Server?

Sql-server – sp_executesql adds statements to executed dynamic script

Related Question