1

A common pattern that I see is:

USE Name_Of_My_Database
GO

As far as I can tell, there is no point to this, is there? I have tried looking for the answer in the places listed below, and it's absent:

What is the use of GO in SQL Server Management Studio & Transact SQL?

In SQL Server, when should you use GO and when should you use semi-colon ;?

https://learn.microsoft.com/en-us/sql/t-sql/language-elements/sql-server-utilities-statements-go

Edit: No, it's not a duplicate, this question is more specific - I didn't find the information I needed in the linked question, though I read it before posting this.

VSO
  • 11,546
  • 25
  • 99
  • 187
  • Possible duplicate of [What is the use of GO in SQL Server Management Studio & Transact SQL?](https://stackoverflow.com/questions/2299249/what-is-the-use-of-go-in-sql-server-management-studio-transact-sql) – S3S Oct 24 '17 at 18:40

2 Answers2

4

There are two big differences between GO and ;:

  1. GO splits the script into different batches.
  2. ; is a statement terminator.

Using GO after a USE DatabaseName is necessary when the following statement requires it to be the first statement in a batch. As an example, the following code will fail:

Use SomeDatabase

Create Procedure spSomeProcedure
As Begin
    Select 1
End

Msg 111, Level 15, State 1, Procedure spSomeProcedure, Line 4
'CREATE/ALTER PROCEDURE' must be the first statement in a query batch.

But adding a GO between them will allow the statement to run:

Use SomeDatabase
Go

Create Procedure spSomeProcedure
As Begin
    Select 1
End

Command(s) completed successfully.

Siyual
  • 16,415
  • 8
  • 44
  • 58
  • I'd also note that go is a SSMS command that you can change to what ever you want. – S3S Oct 24 '17 at 18:41
0

I set my SSMS Scripting Options to not script USE statements. I find them pointless as well, in general.

"GO" isn't a SQL command, it's just a batch separator... it's an SSMS feature (or ISQL/OSQL feature), not a SQL Server feature. It's a way to have one text file contain multiple batches of SQL to send to SQL Server.

pmbAustin
  • 3,890
  • 1
  • 22
  • 33
  • As far as I can tell, `USE Whatever_Db` is just a convenience statement not to have to write the full path later, e.g. `dbo.My_Table` instead of `Whatever_Db.dbo.My_Table`. – VSO Oct 24 '17 at 18:25
  • I literally NEVER use "USE" statements in scripts. It locks the script to one database, meaning if you go and try to run it on another one, it won't actually execute against that database but the one in the USE statement... which can be unintuitive and lead to hard-to-find bugs and issues. I use the drop-down to select the database I want to run a script on. "USE" is no use to me at all. In fact, I BAN its use in our scripts. – pmbAustin Oct 24 '17 at 18:31
  • I never have a USE in my scripts but I use it when I am working. It is easier for me to type that then to stop and grab the mouse to select the database I want to use. :) – Sean Lange Oct 24 '17 at 18:40
  • @pmbAustin This is not true. `USE` doesn’t restrict the script to just the database in the `USE` statement. It just sets the default database of your script to that one. You can most certainly do `USE DatabaseA; SELECT * FROM DatabaseB.dbo.SomeTable`. It’s literally the same as selecting a database from the drop down. It even *sets* the drop down value to the database in the `USE` after executing it. – Siyual Oct 24 '17 at 19:00
  • You're missing the point. It DOES restrict the script to the use of that one database because every time you run it, it changes the database back to that specified in the script. The only way to avoid it is to delete it, or select the entire script EXCEPT the USE statement in order to execute it. If you switch to Database B, and then just run the script, the USE switches it back to Database A and runs the script. VERY bad if you're not expecting that. This is why I ban the use of "USE". – pmbAustin Oct 24 '17 at 19:19