SQL Server should allow declarative specification of temp tables used as parameters - by Greg Low - Australia

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 716565 Comments
Status Closed Workarounds
Type Suggestion Repros 0
Opened 1/4/2012 5:12:05 PM
Access Restriction Public


SQL Server allows stored procedures to create temp tables and to then execute child stored procedures that access those temp tables. Yet there is no declarative way to specify what the child procedure expects.
This makes it impossible for tools such as SQL Server Data Tools to know the difference between an unresolved reference and a valid reference to a temporary table (or its columns).
Sign in to post a comment.
Posted by Microsoft on 1/9/2012 at 11:55 AM
Hello Greg,
Thanks for your feedback. We have no plans to enhance the temporary tables support like you described. If anything, we will enhance the existing table-valued parameters feature to support writes. That should satisfy your goals too. So I am resolving this as "won't fix".

Umachandar, SQL Programmability Team
Posted by Paul White NZ on 1/5/2012 at 11:00 PM
I agree broadly with Jamie and Simon. Down voted because I think this would be a step backward; it would be better if #-named temporary objects went away completely.
Posted by Microsoft on 1/5/2012 at 11:40 AM

Thanks for sharing your thoughts. We will have a look on it and will check if we can make the design change in Denali.

Posted by Simon Sabin on 1/5/2012 at 4:03 AM
I agree with Jamie
Posted by Jamie Thomson on 1/5/2012 at 1:04 AM
Hi Greg,
Although your suggestion is a good one I've decided that its not one that I can vote on because, IMO, it would only encourage something which I see as a bad coding practise. That is, use of temp tables that are instantiated in other stored procs.
I would much rather the product team channel their energies into updateable TVPs rather than supporting antiquated development practises.