g.britton (11/24/2015)
I'm thinking something else is going on, or something is not documented. deferred resolution is documented within the context of creating a stored procedure, which I get.
I'm pretty sure it's deferred compile. A batch behaves the same as a create procedure for the purposes of parsing and binding. Difference is that a batch goes on to be executed directly, while the contents of a create procedure are executed later
The parser won't bind permanent tables that don't exist (compile is deferred until the statement executes, as opposed to the batch), but it appears to do some form of cursory binding or checking on temp tables, probably because it's far more likely for someone to make mistakes like creating the same temp table twice than it is for a permanent table to be created twice in a batch. It's not a full binding, you still see deferred compile on things like a DROP TABLE #DoesntExist
For a perm table, it is as if the parser sees the intervening drop statement and says "well, this changes things!" but not so for temp tables
I think it's more a case that the parser goes "Don't know that table, going to ignore that statement for now, will worry about it at the time that it executes"
RAISERROR ('Hello',10,1)
CREATE TABLE T1 (i INT)
CREATE TABLE T1 (i INT)
Error occurs at the point of the second CREATE TABLE executing
RAISERROR ('Hello',10,1)
CREATE TABLE #T1 (i INT)
CREATE TABLE #T1 (i INT)
Nothing executes, error raised before execution of batch starts
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability