The Dodgy GO Statement

  • hi, the behavior you experience is absolutely by design and no mystery. if you take a close look at BOL, you'll recognize that stored procedures NEVER required BEGIN and END statements. this is just a strange habit that some people seem to have. a stored procedure always starts with CREATE PROC and ends with GO (and that's the reason why it has to be the only statement in a batch).

  • Of Course you do -- If you are going to script in multiple SPs in the same .SQL file. Also if you are going to script in a SP and a grant it some default permissions in the same .SQL file. Also if are going to create an SP and say 'print' out some status messages in the same .SQL file.

    We have faced issues issues like this in our system (using VB and SQL2000, with all business logic implemented as SPs). The author is not saying the GO executes anything in the SP, but how a misplaced GO introduces unintentional behaviour into your SP.


  • cneuhold,

    Thanks for clarifying. It really seems to me that the T-SQL language is not mature and can't match other compiled languages or PL/SQL.

  • I don't know why people post such a bad article, It is waste of time and confuse the new people learning the technology. I request the authour to withdraw this article immediately.

  • Suppose I want to eg. create a view part way through my stored proc. SQL Server will tell me "'CREATE VIEW' must be the first statement in a query batch." In a plain SQL I'd just throw in a GO to terminate the batch before the CREATE VIEW and start a new one.

    Seems to me that's a reason for wanting to be able to use GO in a stored proc. Anyone know what to do about this?

Viewing 5 posts - 16 through 20 (of 20 total)

You must be logged in to reply to this topic. Login to reply