Home Dashboard Directory Help
Search

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


Status: 

Closed
 as Won't Fix Help for as Won't Fix


1
1
Sign in
to vote
Type: Suggestion
ID: 716565
Opened: 1/4/2012 5:12:05 PM
Access Restriction: Public
0
Workaround(s)
view

Description

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).
Details
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
Hi,

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

Regards,
Gaurav
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.

Sorry!

@jamiet
Sign in to post a workaround.