07-31-2023, 08:59 AM
**tldr;** In most cases nowadays GO is mostly IMO optional. Using GO is best in LARGE transaction batches where you would have compiled many different scripts together in a large script and don't want errors where similar variables are used and so that parts of the transaction is committed to the server when desired instead of all of the script being rolled back due to an error.
LARGE TRANSACTION 1 --> Runs Successfully
GO; --> Is in the server
LARGE TRANSACTION 2 --> Runs Successfully
GO; --> Is in the server
LARGE TRANSACTION 3 --> Errors
GO; --> Without the other GO statements this would rollback Transaction 1 & 2
----------
Not sure the best way to provide this SO wise however I do feel like what I've read so far doesn't really sum it all up and include an example that I've come across.
As stated many times before GO simply "commits" a batch of commands to the server.
I think understanding sessions also helps with understanding the necessity (or optionality) of the GO statement.
(This is where my technicality may fail but the community will point it out and we can make this answer better)
Typically developers are working in a single session and typically just executing simple statements to the database. In this scenario GO is optional and really...all one would do is throw it at the end of their statements.
Where it becomes more helpful is probably an option given by [Jamshaid K.][1] where you would have many large transactions that you would want committed in turn instead of all transactions being rolled back when one fails.
The other scenario where this also becomes helpful (which is the only other spot I've experienced it) is where many small transactions are compiled into one large script. For example
Dev 1 makes script 1
Dev 2 makes script 2
Dev 1 makes script 3
In order to deploy them a python script is written to combine the scripts so Script Master = script1 + script 2 + script 3.
GO statements would be required in the 3 scripts otherwise there could be errors where the scripts use conflicting variables or if script 3 fails the transactions from scripts 1 and 2 would be rolled back.
Now this process is probably archaic given current CI/CD solutions out there now but that would probably be another scenario where I could see GO being helpful/expected.
[1]:
LARGE TRANSACTION 1 --> Runs Successfully
GO; --> Is in the server
LARGE TRANSACTION 2 --> Runs Successfully
GO; --> Is in the server
LARGE TRANSACTION 3 --> Errors
GO; --> Without the other GO statements this would rollback Transaction 1 & 2
----------
Not sure the best way to provide this SO wise however I do feel like what I've read so far doesn't really sum it all up and include an example that I've come across.
As stated many times before GO simply "commits" a batch of commands to the server.
I think understanding sessions also helps with understanding the necessity (or optionality) of the GO statement.
(This is where my technicality may fail but the community will point it out and we can make this answer better)
Typically developers are working in a single session and typically just executing simple statements to the database. In this scenario GO is optional and really...all one would do is throw it at the end of their statements.
Where it becomes more helpful is probably an option given by [Jamshaid K.][1] where you would have many large transactions that you would want committed in turn instead of all transactions being rolled back when one fails.
The other scenario where this also becomes helpful (which is the only other spot I've experienced it) is where many small transactions are compiled into one large script. For example
Dev 1 makes script 1
Dev 2 makes script 2
Dev 1 makes script 3
In order to deploy them a python script is written to combine the scripts so Script Master = script1 + script 2 + script 3.
GO statements would be required in the 3 scripts otherwise there could be errors where the scripts use conflicting variables or if script 3 fails the transactions from scripts 1 and 2 would be rolled back.
Now this process is probably archaic given current CI/CD solutions out there now but that would probably be another scenario where I could see GO being helpful/expected.
[1]:
[To see links please register here]