Solución:
GO no es parte del lenguaje TSQL. Es un separador de lotes utilizado por SQLCMD y SSMS.
GO no es una instrucción Transact-SQL; es un comando reconocido por las utilidades sqlcmd y osql y el editor de código de SQL Server Management Studio.
Las utilidades de SQL Server interpretan GO como una señal de que deben enviar el lote actual de instrucciones Transact-SQL a una instancia de SQL Server. El lote actual de declaraciones se compone de todas las declaraciones ingresadas desde el último GO, o desde el inicio de la sesión ad hoc o el script si este es el primer GO.
Una instrucción Transact-SQL no puede ocupar la misma línea que un comando GO. Sin embargo, la línea puede contener comentarios.
Declaraciones de utilidades de SQL Server – GO
Se originó con las interfaces de línea de comandos y persiste en sqlcmd hasta el día de hoy. Puede escribir un lote en varias líneas en la interfaz de línea de comandos, y el lote no se envía al servidor hasta que escribe go.
1> select name, create_date
2> from sys.objects
3> where name="foo"
4> go
name create_date
-------------------------------------------------------------------------------------------------------------------------------- -----------------------
foo 2020-07-20 09:56:42.393
(1 rows affected)
1>
Puede configurar qué usar para un separador de lotes en SSMS. GO es el predeterminado, pero puede ser cualquier otra cosa.
Divide el comando en lotes individuales.
Por ejemplo, el alcance de las variables termina con GO.
; separa los comandos pero no finaliza el alcance.
GO separa lotes y termina el alcance.
Puede pensar en ello como si todo el comando se dividiera por GO y cada parte se ejecutó per se.
es decir.
Esto funciona:
declare @a int;
set @a = 1;
select @a
Pero esto no funciona:
declare @a int
set @a = 1
GO
select @a -- will throw error as variable is not declared
GO se ha abordado bien en otras respuestas. Permítanme agregar algo sobre el punto y coma:
Hace mucho, mucho tiempo, esto no era algo que usáramos. Pero el estándar SQL (ANSI / ISO SQL) especificaba que una declaración SQL debería terminar con punto y coma. Entonces, en una determinada versión, MS le permitió cumplir con ANSI SQL. Pero fue, y en su mayor parte sigue siendo, una operación no operativa. Es decir, no importa si lo tienes o no
No participé cuando se inventó el lenguaje SQL (era un niño), pero puedo imaginar que el punto y coma se especificó como un terminador de declaración para simplificar el análisis de SQL. Es decir, cuando envía SQL al motor de base de datos, primero tiene que analizar (entender lo que dijo, básicamente) la declaración (s). Probablemente pueda imaginar que podría ser más fácil para el código de análisis en el motor si pudiera buscar algún carácter que signifique “fin de instrucción”. De ahí el punto y coma. Pero como señalé, SQL Server no usó punto y coma para analizar.
Ahora, con el tiempo, se introdujeron algunos elementos nuevos del lenguaje requerido que la declaración anterior se terminó con punto y coma (WITH como en CTE y THROW son dos ejemplos). Sin él, SQL Server no podría analizar (entender lo que dijo) y se generó un error en la fase de análisis.
En un momento, la EM dijo que no terminar una declaración con punto y coma estaba en desuso. Es decir, intentaron hacernos creer que en algún momento (algún lanzamiento futuro), tener para terminar todas nuestras declaraciones con punto y coma. Probablemente no fui el único a quien le pareció un poco divertido, ¡imagina los aspectos de compatibilidad con versiones anteriores! Saltando a la actualidad, si lee la documentación, se da cuenta de que este ya no es el caso (de hecho, hay no obsoleto presentado hoy – ¡ninguno!).