code completion in SSMS

Hi!

Do you plan to implement following features into your code completion engine:
- displaying temporary tables names
- displaying columns for temporary tables and table variables

It would be surely nice to have, but it is not possible without executing the code. We may add some limited support for straightforward cases like
CREATE TABLE #temp
(
.....
)

and DECLARE @my_tab TABLE (….)

But again, there is no real way to use code parsing to pickup temp table definitions. Even SQL Server doesn't know what would be in these tables until the code is actually executed. This is especially true, when temp tables are defined and used in different procedures or defined outside of procedures.

Just to give you a couple of ideas why it is not doable

CREATE TABLE #t1 (a int)
.. 500 lines of code here...
ALTER TABLE #t1 ADD COLUMN b int
ALTER TABLE #t DROP COLUMN a
.. 500 lines of code here...
SELECT * INTO #t2 FROM #t1

SELECT #t2.[a popup would be nice here] but what do we expect in this popup?

Another case
SELECT * INTO #t2 FROM my_table_function(1, 2, 3) JOIN my_other_table ON col1 = col2

What are we going to have in #t2 in this case?

I agree with your arguments that it is really impossible to implement code completion for any cases that concern temporary tables. But I still believe that it is possible when you deal with table variables and temporary tables that were explicitly declared in the same batch. More of that, I think that explicit declaration is the only correct way to declare temporary tables for ones declared in other manner are a potential cause of performance issues. Altering temporary table structure isn't good practice as well (for the same reason). You see, it's all my humble opinion of course, but it's based on everyday production environment DBA practice :)

In simple cases when temp tables and table variables are created statically in the same simple batch, their definition can be parsed out, but only in simple cases. In sophisticated applications when table definitions are not known in run-time or for other reasons and considerations are created/populated outside of the batch, in which they are referenced, or just created dynamically using dynamic SQL, it would not be possible to parse them.