Missing BEGIN and END?
I am pretty sure what is going on but wanted to get some ideas from my fellow SQL Server Travelers (actually it is fairly obvious what is going on but I think makes for an interesting discussion).

Riddle me this Batman... what is up with this?

    CREATE PROCEDURE ToBeDropped
    AS
    BEGIN
    PRINT 'Drop me!';
    END
    DROP PROCEDURE ToBeDropped;

What happens? My first thought was the procedure gets created then immediately dropped. Wrongo! And you probably thought the same unless you already knew this about issue from before... admit it!

In SSMS hit Ctrl-T to switch Query Results to Text. Then run the following (or you could script the new procedure ToBeDropped):

    SELECT m.[definition]
    FROM sys.sql_modules AS m INNER JOIN sys.objects AS obj
    ON m.object_id = obj.object_id
    WHERE obj.name = 'ToBeDropped';

Next run the procedure:

    EXECUTE ToBeDropped;

The rerun the above sys.sql_modules query or attempt to script the object. You can't because it no longer exists.

Hmmm... What's going on here? Clearly there is an implicit BEGIN and END to the while procedure, similar to the following:

    CREATE PROCEDURE ToBeDropped
    AS
    BEGIN
    BEGIN
    PRINT 'Drop me!';
    END
    DROP PROCEDURE ToBeDropped;
    END;

Which when formatted better looks like the following:

    CREATE PROCEDURE ToBeDropped
    AS
    BEGIN
        BEGIN
            PRINT 'Drop me!';
        END

        DROP PROCEDURE ToBeDropped;
    END ;

I am not a big fan of implicit behavior. I prefer being explicit. TSQL is moving in the direction of becoming more "real" - see the semicolon and all the CLR functionality now available or potentially available in TSQL. I would like to see a CREATE PROCEDURE body be required to have at least 1 BEGIN and END pair - heck make { be an alias/synonym for BEGIN and } an alias/synonym for END - and we would be one step closer to TSQL turning into C#.

Thoughts? Opinions? Thanks!
Missing BEGIN and END?
===

I am pretty sure what is going on but wanted to get some ideas from my fellow SQL Server Travelers (actually it is fairly obvious what is going on but I think makes for an interesting discussion).

Riddle me this Batman... what is up with this?

    CREATE PROCEDURE ToBeDropped
    AS
    BEGIN
    PRINT 'Drop me!';
    END
    DROP PROCEDURE ToBeDropped;

What happens? My first thought was the procedure gets created then immediately dropped. Wrongo! And you probably thought the same unless you already knew this about issue from before... admit it!

In SSMS hit Ctrl-T to switch Query Results to Text. Then run the following (or you could script the new procedure ToBeDropped):

    SELECT m.[definition]
    FROM sys.sql_modules AS m INNER JOIN sys.objects AS obj
    ON m.object_id = obj.object_id
    WHERE obj.name = 'ToBeDropped';

Next run the procedure:

    EXECUTE ToBeDropped;

The rerun the above sys.sql_modules query or attempt to script the object. You can't because it no longer exists.

Hmmm... What's going on here? Clearly there is an implicit BEGIN and END to the while procedure, similar to the following:

    CREATE PROCEDURE ToBeDropped
    AS
    BEGIN
    BEGIN
    PRINT 'Drop me!';
    END
    DROP PROCEDURE ToBeDropped;
    END;

Which when formatted better looks like the following:

    CREATE PROCEDURE ToBeDropped
    AS
    BEGIN
        BEGIN
            PRINT 'Drop me!';
        END

        DROP PROCEDURE ToBeDropped;
    END ;

I am not a big fan of implicit behavior. I prefer being explicit. TSQL is moving in the direction of becoming more "real" - see the semicolon and all the CLR functionality now available or potentially available in TSQL. I would like to see a CREATE PROCEDURE body be required to have at least 1 BEGIN and END pair - heck make { be an alias/synonym for BEGIN and } an alias/synonym for END - and we would be one step closer to TSQL turning into C#.

Thoughts? Opinions? Thanks!