SSMS – How to Remove the Need for ‘GO’

ssms

Is there a way to cause every statement to be sent to the server immediately, or in its own batch, in SSMS?

I am working on a large set of statements within which I alter tables, disable/enable temporal history, change values, etc., and SSMS seems to be getting in the way in a big way. If I ran the commands as normal in a CLI, or I select-and-run manually, it works. However for some reason in SSMS I need to insert go statements in between everything in order for it to work.

For example, adding a column and then subsequently updating its values, without go it tells me the column name is invalid, with go it works as expected. I can only imagine that SSMS is somehow interpreting the commands and comparing to its idea of the tables and causing the "error"–not the server.

I would prefer a statement like go away at the start of the whole set/file, to make it actually run each line as-is. Is this possible?

Best Answer

The short answer is no, it cannot be turned off.

GO is a 'batch terminator'. When SSMS executes 'statements' they are 'batched' together. This could be a single query, an entire script with no 'GO's or could be the code between 'GO's.

That is why you are getting the errors when you are trying to add a column and update it in one hit. They need to execute as separate batches.

It is also possible that, say you had 3 statements separated into batches that a single batch in a script could fail but not the entire script.

Query1 -- success
GO
Query2 -- failed
GO
Query3 -- success
GO

GO is not a Transact SQL Statement, it is a command recognised by SSMS and sqlcmd. See here on MSDN for more details.

You will also find that variables do not persist past a GO statement and must be re-declared or your statement/batch sequence amended.

Incidentally, you don't have to use 'GO' as a batch terminator, you could use anything. It can be amended from the Tools-->options menu, under query execution. Be aware though, changing it and using something different will only work for the copy of SSMS you are using. If you are working in a team, and every member of the team has not changed to use 'NewBatch' keyword then the script will fail in their copy of SSMS (as I'm fairly confident it does in sqlcmd too!).

Related Question