Very true. Table variables definitely have their place, especially when dealing with smaller amounts of data. (Nice post on table variables, by the way.)

However, the table variables will still be around (just like temp tables) if I’m messing around in SSMS before I run a CREATE PROCEDURE and commit my changes to the database. I can’t tell you the number of times I’ve forgotten to remove a temporary table. Then I look like an idiot in front the developers and they get one more reason to mock me apart from my TSQL license plate.

Plus, when you’re working with dynamic SQL, temp tables are reused by the code you execute via sp_executesql, whereas table variables are not (they’re out of scope), so you’ll have to make multiple calls to retrieve the same data. This way I can build dynamic SQl that uses the contents of temp tables for decision making as well as for joins in the final query.

Also, table variables are always assumed to have 1 row by the algebrizer. For my needs, the limitations of table variables render them largely useless since I deal largely with dynamic SQL working to aggregate large result sets (see Should I use a #temp table or a @table variable? for more). I’m including the link for others following along, not because I think you don’t know any better.