Comments on: SQL SERVER – Bad Practice of Using Keywords as an Object Name – Avoid Using Keywords as an Object

By: SQLAuthority News – An Year Worth Remembering and Looking Forward to Better Next Year « SQL Server Journey with SQLAuthority

Sat, 31 Dec 2011 01:31:40 +0000

[...] January: SQL SERVER – 2008 – Missing Index Script – Download and SQL SERVER – Copy Statistics from One Server to Another Server February: SQL SERVER – Summary of Month – Wait Type – Day 28 of 28 March: SQL SERVER – ‘Denali’ – A Simple Example of Contained Databases April: SQL SERVER – Introduction to SQL Azure – Creating Database and Connecting Database May: SQL SERVER – Copy Database from Instance to Another Instance – Copy Paste in SQL Server June: SQL SERVER – Solution – Puzzle – Statistics are not Updated but are Created Once July: SQL SERVER – Interview Questions and Answers – Frequently Asked Questions – Complete Downloadable List – Day 0 of 31 August: SQL SERVER – Tips from the SQL Joes 2 Pros Development Series – All about SQL Constraints – Day 22 of 35 September: SQL SERVER – Denali – Conversion Function – Difference between PARSE(), TRY_PARSE(), TRY_CONVERT() October: SQL SERVER – Quick Note about JOIN – Common Questions and Simple Answers November: SQL SERVER – Puzzle to Win Print Book – Functions FIRST_VALUE and LAST_VALUE with OVER clause and ORDER BY December: SQL SERVER – Bad Practice of Using Keywords as an Object Name – Avoid Using Keywords as an Objec… [...]

By: thomasrushton

thomasrushton — Fri, 09 Dec 2011 18:05:17 +0000

You can change the batch delimiter used by SSMS from “GO” to “xyzzy”, or “8″, or pretty much anything you want. Jonathan @fatherjack Allen did a demo at SQLBits recently showing some of the weirdness that can happen if you set it to a number…

In SSMS, go to “Tools”, “option”, “Query Execution”, “SQL Server”. And there you have the option to change the batch separator. See http://msdn.microsoft.com/en-us/library/ms180280.aspx

By: Ashish Jain

Ashish Jain — Fri, 09 Dec 2011 10:37:38 +0000

Hi Pinal Sir,
Very Informative post.
Thanks to you and DHall

By: lalit

lalit — Fri, 09 Dec 2011 08:58:36 +0000

Really a nice observation as well fact.

Pinal , can we have an article on debuggin T-SQL in SSMS.
I am googling on it , but couldn’t get any simpler article. I anticipate your’s one will be of great help.

-Lalit

By: Chirag Satasiya

Chirag Satasiya — Fri, 09 Dec 2011 05:48:15 +0000

Hi pinal sir,
thanks for the updates..
Useful and informative article..

Regard$
Chirag Satasiya

By: Pankaj Nikam

Pankaj Nikam — Fri, 09 Dec 2011 05:10:47 +0000

Awesome Gotcha! Thanks for the repost.

By: pinaldave

pinaldave — Fri, 09 Dec 2011 04:03:47 +0000

DHall,

Thank you for your comment. Your comment is much more informative and complete compared to original blog posts :)

Thanks for spending time and sharing this with us.

Good Learning and I will say again that I just learned!

By: DHall

DHall — Fri, 09 Dec 2011 03:29:56 +0000

The second point you make isn’t exactly accurate. The semicolon has nothing (or very little) to do with executing the GO stored procedure. The code works the same even without the semicolon as long as EXEC and GO are on the same line or if [GO] is wrapped in square brackets.

However, if the GO proc name is the only thing (other than an optional comment) on the line following following the EXEC command, then the SQL query window will try to interpret it as a batch delimiter if it’s not followed by a semicolon or wrapped in square braces.

In other words, the following SQL will work as expected

INSERT INTO T1(ID) exec GO — Note no semicolon
SELECT * FROM T1

– and so will this:
INSERT INTO T1(ID) exec
GO; — Note the semicolon
SELECT * FROM T1

– and so will this:
INSERT INTO T1(ID) exec
[GO] — Note the square brackets but no semicolon
SELECT * FROM T1

– but this won’t:

INSERT INTO T1(ID) exec
GO — Note no semicolon
SELECT * FROM T1

Another evidence that GO is different from SQL reserved word is to duplicate your experiment using [TABLE] as the proc name instead of GO. You’ll note that unlike the word GO, the word TABLE must be wrapped in square brackets so that TSQL will allow it to be an object name. For GO, the square brackets are optional.

– The following code works fine
CREATE PROCEDURE [TABLE]
AS SELECT 1 AS NUMBER
GO
INSERT INTO T1(ID) exec [TABLE] — Note the square brackets
SELECT * FROM T1

– but this generates a syntax error
CREATE PROCEDURE [TABLE]
AS SELECT 1 AS NUMBER
GO
INSERT INTO T1(ID) exec TABLE — Note no square brackets
SELECT * FROM T1

As you mention in your first point, using keywords in this manner can be trouble, and should generally be avoided for many reasons, but it especially helps in this case to understand that GO is not a reserved word in TSQL, but only in some of the tools (like SSMS) that process SQL queries in batches.

The following excerpt from SQL BOL should help clarify the difference between the GO batch delimiter and true SQL reserved words.

GO is not a Transact-SQL statement; it is a command recognized by the sqlcmd and osql utilities and SQL Server Management Studio Code editor.

SQL Server utilities interpret GO as a signal that they should send the current batch of Transact-SQL statements to an instance of SQL Server. The current batch of statements is composed of all statements entered since the last GO, or since the start of the ad hoc session or script if this is the first GO.

A Transact-SQL statement cannot occupy the same line as a GO command. However, the line can contain comments.