Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


The Dodgy GO Statement


The Dodgy GO Statement

Author
Message
Subramanyam...
Subramanyam Krishnamurthy-120784
SSC Rookie
SSC Rookie (33 reputation)SSC Rookie (33 reputation)SSC Rookie (33 reputation)SSC Rookie (33 reputation)SSC Rookie (33 reputation)SSC Rookie (33 reputation)SSC Rookie (33 reputation)SSC Rookie (33 reputation)

Group: General Forum Members
Points: 33 Visits: 1
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/sKrishnamurthy/thedodgygostatement.asp


Kindest Regards,

Mani

colin naylor
colin naylor
Old Hand
Old Hand (345 reputation)Old Hand (345 reputation)Old Hand (345 reputation)Old Hand (345 reputation)Old Hand (345 reputation)Old Hand (345 reputation)Old Hand (345 reputation)Old Hand (345 reputation)

Group: General Forum Members
Points: 345 Visits: 19

The author seems to think that begin and end statements seem to do something in stored procedures where they do not.

You can put a begin and end statement around whatever you like, but it wont stop the batch from continuing on to what comes next.

You also don't even need a GO statement in order to create a stored procedure. The authors seems to have totally missed the purpose of the GO statement.

Did you know, that SQL Server doesn't even understand a GO statement. It is not transact SQL!

Hope this helps.


Alan Harley
Alan Harley
SSC Journeyman
SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)

Group: General Forum Members
Points: 84 Visits: 156

Do you really understand what happens when you create a stored procedure?

Interesting question! I agree with the above poster. The BEGIN and END statements are nothing to do with stored procedures but are simply used to logically group statements in IF's/ELSE's, WHILE's and CASES's.


Fattman
Fattman
Valued Member
Valued Member (73 reputation)Valued Member (73 reputation)Valued Member (73 reputation)Valued Member (73 reputation)Valued Member (73 reputation)Valued Member (73 reputation)Valued Member (73 reputation)Valued Member (73 reputation)

Group: General Forum Members
Points: 73 Visits: 79

With you there. There's more to GO than meets the eye, and it doesn't even have to be "GO" either!

Thort it might be fun to share this early tale of GO horror (I was a lot younger then):

SQL 7, asked to implement a script from a (VB) developer to add a column to a table on a remote, client mission-critical, really, really, really important customer address db.

So, did I double-check the code? No.

Did I test it on a local db? No.

Can you see a disaster coming? Oh, yes...

Run the script. See the script run. See the error.

Turns out VB Fly Boy had scripted the change from Enterprise Mangler and it went something like this:

SELECT * INTO newtable FROM oldtable

GO

DROP TABLE oldtable

GO

CREATE TABLE oldtable (with shiny new column)

GO

INSERT oldtable SELECT * FROM newtable

GO

Okey-dokey, except the first SELECT INTO failed. But, thanks to the joys of "GO" the script ploughed on, dropped the table etc. So, ended up with the new table with its new column and no data!

Oops. Well, that'd be ok 'cos the local dba on the ground will have a back up. Well, yes, from 3 months ago.

Lots and lots of lessons learned there. I now spend my days doing macrame.





Peter Kryszak
Peter Kryszak
Ten Centuries
Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)

Group: General Forum Members
Points: 1270 Visits: 3
I wonder if some of the confusion is from people transitioning from Oracle PL/SQL and other compiled languages where the language is much more sophisticated and clear.

CREATE/BEGIN/END have clear syntactical and semantic roles in PL/SQL. In fact, the END statement includes the name of the procedure or function that is being defined.

SUB/END SUB and FUNCTION/END FUNCTION in VB.NET are also very clear.

T-SQL still seems like a toy language compared to others for this and some other reasons.

--Peter



Mike C
Mike C
SSCommitted
SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)

Group: General Forum Members
Points: 1523 Visits: 1168
"GO" is not a real SQL statement. It's a batch termination indicator for Query Analyzer. You might want to point out that trying to use "GO" in your scripts outside of Query Analyzer (like in a .NET SqlCommand), you can expect to catch some exceptions.
colin naylor
colin naylor
Old Hand
Old Hand (345 reputation)Old Hand (345 reputation)Old Hand (345 reputation)Old Hand (345 reputation)Old Hand (345 reputation)Old Hand (345 reputation)Old Hand (345 reputation)Old Hand (345 reputation)

Group: General Forum Members
Points: 345 Visits: 19

I think I already said that GO wasn't a real sql statement in my earlier message.

Are we surprised that we haven't heard from the author?


sheepoo
sheepoo
SSC-Enthusiastic
SSC-Enthusiastic (135 reputation)SSC-Enthusiastic (135 reputation)SSC-Enthusiastic (135 reputation)SSC-Enthusiastic (135 reputation)SSC-Enthusiastic (135 reputation)SSC-Enthusiastic (135 reputation)SSC-Enthusiastic (135 reputation)SSC-Enthusiastic (135 reputation)

Group: General Forum Members
Points: 135 Visits: 34
I am having real trouble understanding where I would use this 'approach' in real-world scenarios. In my experience with SQL Server (almost 2 years now) I have not come across one situation where the GO keyword caused me trouble. I use the SQLIDE Pro from Imceda/QUEST and the only time it uses the GO keyword is to do


SET QUOTED_IDENTIFIER ON
GO
SET ANSI_NULLS ON
GO


at the start and

GO
SET QUOTED_IDENTIFIER OFF
GO
SET ANSI_NULLS ON
GO

at the end: I never had to use the GO keyword within a stored procedure.
Maybe I am missing something here
colin naylor
colin naylor
Old Hand
Old Hand (345 reputation)Old Hand (345 reputation)Old Hand (345 reputation)Old Hand (345 reputation)Old Hand (345 reputation)Old Hand (345 reputation)Old Hand (345 reputation)Old Hand (345 reputation)

Group: General Forum Members
Points: 345 Visits: 19

No, you're not missing anything. You don't have to use the GO word when creating stored procs.


sheepoo
sheepoo
SSC-Enthusiastic
SSC-Enthusiastic (135 reputation)SSC-Enthusiastic (135 reputation)SSC-Enthusiastic (135 reputation)SSC-Enthusiastic (135 reputation)SSC-Enthusiastic (135 reputation)SSC-Enthusiastic (135 reputation)SSC-Enthusiastic (135 reputation)SSC-Enthusiastic (135 reputation)

Group: General Forum Members
Points: 135 Visits: 34

Colin, thanks for the backup.

That was exactly my point: You can live without GO as far as creating Stored Procedures are concerned (this being the point discussed in the article)
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search