Executing a command string with GO at the end - sql

I need to execute a command string with using GO command at the end like
exec('SELECT * FROM tblTmp where Id = 1 GO')
After executing I have
Incorrect syntax near 'GO'.
If I execute exec('SELECT * FROM tblTmp GO') everything is OK
What's the issue here?
Thank you.

GO is not an SQL command, it is a batch separator understood by clients like osql, sqlcmd, and SSMS but not the engine itself.
If you write something like this in SSMS:
SELECT 1
GO
SELECT 2
GO
, the engine sends two batches with one statement in each instead of one batch with two statements.
In your second query, GO is treated as an alias to the table tblTmp.
Just remove GO from your query.

You do not need to use GO for a single SQL statement. Only when you're batching several statements into a single script do you need to use a separator. Also, if you're executing these programmatically you should be using the semicolon (;) statement terminator instead of GO to separate your SQL statement.
Here's a handy SQL Server Central article on the usage of GO and the semicolon.

Related

SQL*Plus how to execute multiple queries in single line?

In SQL*Plus, I want to execute multiple SQL queries in single line like
create table emp(name varchar2(20)); desc emp;
I tried executing this one but didn't work for me.
BEGIN OPEN :1 FOR SELECT * FROM table1; OPEN :2 FOR SELECT * FROM table2; END;
is there any way to accomplish this?
Thanks in advance!
SQL*Plus expects either:
A single SQL command, terminated by either a ";" character or a "/" on a line by itself.
A PL/SQL block
A SQL*Plus command
What you have entered is 2 queries on a single line, which SQL*Plus will send to the RDBMS - Oracle will then try and parse the string sent as a single query and fail because it is not valid SQL.
A quick workaround would be to have all your commands in a sql file and run them using #file.sql

Do I have to write the "GO" word in order to execute an SQL server statement?

I have little to no experience with TSQL and SQL Server - so in MySQL when I want to execute a statement I simply write:
Select * from users
...and then hit ENTER.
However now I see many SQL Server tutorials that you have the GO word immediately after each statement. Do I have to write this? For example:
Select * from users; GO
Or I can simply write:
Select * from users; <enter key pressed...>
In SQL Server, go separates query batches. It's optional in most situations.
In earlier versions of SQL Server, you had to do a go after altering a table, like:
alter table MyTable add MyColumn int
go
select MyColumn from MyTable
If you didn't, SQL Server would parse the query batch, and complain that MyColumn didn't exist. See MSDN:
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.
GO separates batches, as Andomar wrote.
Some SQL statements (e.g. CREATE SCHEMA) need to be the first or only statements within a batch. For example, MSDN states
The CREATE PROCEDURE statement cannot
be combined with other Transact-SQL
statements in a single batch.
Local variables are also limited to a batch, and therefore are not accessible after a GO.
Go is optional, no need to write that in your sql statements.
You don't have to. What the GO will do is execute each statement (at least in Sql Server)
As the other answerers said before me, you don't really NEED Go.
There is only one case when you have to use it, and that's when you want to create a table or view and then select from it.
For example:
create view MyView as select * from MyTable
go
select * from MyView
Without Go, Sql Server won't execute this because the select statement is not valid, because the view doesn't exist at that moment.

SQL Server: Do I need to use GO statements between batches?

I have seen people use GO statement between batches of SQL code, but AFAICS it is not mandatory (SQL Server 2008). What are the benefits using GO statements between batches/sets of SQL statements?
They're not strictly required - they're just instructions for the SQL Server Management Studio to execute the statements up to this point now and then keep on going. GO is not a T-SQL keyword or anything - it's just an instruction that works in SSMS.
Sometimes, you need a GO - e.g. if you add a column to a table, and then want to select it again, you need to have a GO between the adding of the column, and the query of it.
E.g. if you try to execute this, you'll get errors from SSMS:
ALTER TABLE (sometable) ADD DateTimeStamp DATETIME
SELECT ID, DateTimeStamp FROM (sometable) WHERE ID > 5
Results in:
Msg 207, Level 16, State 1, Line 9
Invalid column name 'datetimestamp'.
The point is: SSMS is trying to verify the whole statement at once, but on the SELECT statement, it will complain about the missing DateTimeStamp column.
ALTER TABLE (sometable) ADD DateTimeStamp DATETIME
GO
SELECT ID, DateTimeStamp FROM (sometable) WHERE ID > 5
If you put a GO between the two statements, it'll work, because SSMS won't parse and verify the whole statement ahead of time - it will do the first part, and then only parse the second (after the GO).
But other than situations like this one, GO is hardly ever required.
It's only mandatory in SQL tools to tell SSMS where the batch start and end is. It's also required for some statements such as CREATE TRIGGER which must the first in the batch
For example, in a c# to SQL Server call it has no meaning

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

I’ve always been confused with when I should use the GO keyword after commands and whether a semi-colon is required at the end of commands. What is the differences and why/when I should use them?
When I run the Generate-script in SQL Server Management Studio, it seems to use GO all over the place, but not the semi-colon.
GO only relates to SSMS - it isn't actual Transact SQL, it just tells SSMS to send the SQL statements between each GO in individual batches sequentially.
The ; is a SQL statement delimiter, but for the most part the engine can interpret where your statements are broken up.
The main exception, and place where the ; is used most often is before a Common Table Expression Statement.
The reason why you see so many GO's in Generated DDL scripts is because of the following rule about batches.
CREATE DEFAULT, CREATE FUNCTION,
CREATE PROCEDURE, CREATE RULE, CREATE
TRIGGER, and CREATE VIEW statements
cannot be combined with other
statements in a batch. The CREATE
statement must begin the batch. All
other statements that follow in that
batch will be interpreted as part of
the definition of the first CREATE
statement.
One of the use cases for Generated DDL is to generate multiple objects in a single file. Because of this a DDL generator must be able to generate batches. As others have said the GO statement ends the batch.
GO
Go is a batch separator. This means that everything in that batch is local to that particular batch.
Any declarations of Variables, Table Variables, etc do not go across GO statements.
#Temp tables are local to a connection, so they span across GO statements.
Semicolon
A Semicolon is a statement terminator. This is purely used to identify that a particular statement has ended.
In most cases, the statement syntax itself is enough to determine the end of a statement.
CTE's however, demand that the WITH is the first statement so you need a semicolon before the WITH.
You should use a semi-colon to terminate every SQL statement. This is defined in the SQL Standards,
Sure, more often than not SQL Server allows you to omit the statement terminator but why get into bad habits?
As others have pointed out, the statement preceding a common table expression (CTE) must be terminated with a semi-colon. As a consequence, from folk who have not fully embraced the semi-colon terminator, we see this:
;WITH ...
which I think looks really odd. I suppose it makes sense in an online forum when you can't tell the quality of code it will be pasted into.
Additionally, a MERGE statement must be terminated by a semi-colon. Do you see a pattern here? These are a couple of the newer additions to TSQL which closely follow SQL Standards. Looks like the SQL Server team are going down the road of mandating the use of the semi-colon terminator.
GO is a batch terminator, a semi-colon is a statement terminator.
you will use GO when you want to have multiple create proc statements in 1 script because create proc has to be the first statement in a batch. If you use common table expressions then the statement before it needs to be terminated with a semi-colon

What is the difference between ";" and "GO" in T-SQL?

I use ADO.NET as well as the sqlcmd utility to send SQL scripts to SQL Server 2008. What is the difference between using ; and GO to separate chunks of SQL?
GO is not actually a T-SQL command. The GO command was introduced by Microsoft tools as a way to separate batch statements such as the end of a stored procedure. GO is supported by the Microsoft SQL stack tools but is not formally part of other tools.
You cannot put a GO into a string of SQL and send it as part of a ADO.NET command object as SQL itself does not understand the term. Another way to demonstrate this is with the profiler: set up some statements that use GO in Query Analyzer/Management Studio and then run the profiler when you execute. You will see they are issued as separate commands to the server.
The semi-colon is used to signify the end of a statement itself, not necessarily a whole batch.
http://msdn.microsoft.com/en-us/library/ms188037.aspx
"GO" is similar to ; in many cases, but does in fact signify the end of a batch.
Each batch is committed when the "GO" statement is called, so if you have:
SELECT * FROM table-that-does-not-exist;
SELECT * FROM good-table;
in your batch, then the good-table select will never get called because the first select will cause an error.
If you instead had:
SELECT * FROM table-that-does-not-exist
GO
SELECT * FROM good-table
GO
The first select statement still causes an error, but since the second statement is in its own batch, it will still execute.
GO has nothing to do with committing a transaction.
semicolon is a statement separator. The previous statement(s) is not necessarily executed when a semicolon is encountered.
GO
Signifies the end of a batch. Executes the previous batch of statements, as does encountering the end of the block.
GO 2
Means execute the batch that many times. I think I've used that option maybe twice in my life. Then again, I'm not a DBA by trade.
Under SQL Server TSQL (2005 - 2016) bear in mind that:
Semicolon (;) is a block terminator.
GO is a batch terminator.
Additionally, GO can be used to invoke the same DML block multiple times using the following syntax:
GO [count]
Where [count] is a positive integer that indicates how many times the TSQL block of commands preceding said GO are to be carried out over and over.
Also, unlike semicolon, GO is mandatory before a new DDL, say, when you create a new view, since a semicolon separating previous commands will trigger an error. For example:
drop view #temporary_viewGO
create view #another_view...
--> NO ERRORS
If you replaced GO with a semicolon in the previous example, it will raise the following error message:
'CREATE VIEW' must be the first statement in a query batch.
'GO' is typically used to indicate the end of a batch of SQL statements which means that you could have a begin transaction and end transaction wrapped up into a single collection of statements that could fail or succeed together.
';' is generally used to separate multiple SQL statements from one another. This is noticable in SQL scripts that need to return multiple recordsets, such as `select * from table1; select * from table2;' which would result in two separate recordsets on the client's side.
The command GO means the end of a batch.
Therefore all variables declared before GO are invalid after the GO command.
Against the semicolon does not end the batch.
If You will use a DML command in a procedure, use the semicolon instead GO.
For example:
CREATE PROCEDURE SpMyProc
#myProcParam VARCHAR(20)
AS
DECLARE #myOtherParam INT = 5
;DISABLE TRIGGER ALL ON tMyTable
UPDATE tMyTable SET myVar = #myProcParam, mySecondVar = #myOtherParam
;ENABLE TRIGGER OLL ON tMyTable
I thought the ; character separates a list of SQL commands, GO just instructs SQL Server to commit all the previous commands.