This is maybe a dumb question, but what difference does the ; make after a
statement in a sp, view etc.
My thought is that when using ; after a statement I tell the query engine
that a statement is finished and it can go on to the next. This way it don't
have to make that assumption self, how it now does it, and this can push
performance just a little.
Or is it just there for human readability.
Just curious.It's an indicator that you've reached the end of the statement. It's
especially handy when sending SQL statements from a client application,
where you might have multiple statements in a single string/on a single
line. I suppose it can also help readability, since it gives you a visual
cue that you've reached the end of a statement. I don't think it helps
improve performance (speed) considerably.
"Senna" <Senna@.discussions.microsoft.com> wrote in message
news:B9A504EE-8F1F-4048-BF60-16CB2341B9CF@.microsoft.com...
> Hi
> This is maybe a dumb question, but what difference does the ; make after a
> statement in a sp, view etc.
> My thought is that when using ; after a statement I tell the query engine
> that a statement is finished and it can go on to the next. This way it
> don't
> have to make that assumption self, how it now does it, and this can push
> performance just a little.
> Or is it just there for human readability.
> Just curious.|||Thats a questionmark less. Thanks. :)
"Mike C#" wrote:
> It's an indicator that you've reached the end of the statement. It's
> especially handy when sending SQL statements from a client application,
> where you might have multiple statements in a single string/on a single
> line. I suppose it can also help readability, since it gives you a visual
> cue that you've reached the end of a statement. I don't think it helps
> improve performance (speed) considerably.
> "Senna" <Senna@.discussions.microsoft.com> wrote in message
> news:B9A504EE-8F1F-4048-BF60-16CB2341B9CF@.microsoft.com...
>
>|||>> My thought is that when using ; after a statement I tell the query engine
that a statement is finished and it can go on to the next. <<
Yes. Look at the BNF in the SQL Standards. T-SQL has a weirdness about
not using the semi-colon in places, but allowing you to finish a
sequence of statements with a "GO" keyword.|||"--CELKO--" <jcelko212@.earthlink.net> wrote in message
news:1150573096.273512.178410@.g10g2000cwb.googlegroups.com...
> Yes. Look at the BNF in the SQL Standards. T-SQL has a weirdness about
> not using the semi-colon in places, but allowing you to finish a
> sequence of statements with a "GO" keyword.
>
"GO" is *NOT* a T-SQL keyword. It is an *end-of-batch* indicator used by
Query Analyzer. Don't be

advice on T-SQL.|||The very first article I ever wrote about SQL Server was about GO, and that
was over 10 years ago.
People still do not understand it.
GO is not a TSQL keyword or command. It is not understood by the TSQL
parser.
GO is a signal to the query too, be it Query Analyzer, osql, sqlcmd or the
Query Window in SQL Server Management Studio. It tells the tool to combine
everything up to that point into a batch and send it to the SQL Server
Engine to be processed as a unit.
If you're using a programming interface to send commands to SQL Server, the
GO is never included.
--
HTH
Kalen Delaney, SQL Server MVP
"--CELKO--" <jcelko212@.earthlink.net> wrote in message
news:1150573096.273512.178410@.g10g2000cwb.googlegroups.com...
> Yes. Look at the BNF in the SQL Standards. T-SQL has a weirdness about
> not using the semi-colon in places, but allowing you to finish a
> sequence of statements with a "GO" keyword.
>|||> Yes. Look at the BNF in the SQL Standards. T-SQL has a weirdness about
> not using the semi-colon in places, but allowing you to finish a
> sequence of statements with a "GO" keyword.
Hey Mr. "CASE is an expression not a statement, idiot!", GO is a batch
separator, not a keyword! Have you ever tried to include GO inside a stored
procedure? If you're unlucky, you'll just get an incomplete procedure:
CREATE PROCEDURE dbo.foo
AS
PRINT '1';
GO
PRINT '2';
GO
EXEC dbo.foo;
GO
DROP PROCEDURE dbo.foo;
GO
Or, if you have (imho) better coding practices, the procedure won't get
created at all:
CREATE PROCEDURE dbo.foo
AS
BEGIN
PRINT '1';
GO
PRINT '2';
END
GO
Don't worry, this throws a lot of people who have been in the industry for
less time than you have. I respect you and everything, but the more I watch
you berate and/or "educate" people, the less I believe you actually USE the
product, much less for real-world business applications.
A|||While it's mostly optional, there are a few cases where it is required.
Early in the history of TSQL for reasons that are clouded in the mists of
the past, it was decided that it would be

statement terminator. When the parser came across a keyword that was valid
as the first word of a statement (SELECT, UPDATE, DELETE, etc.) the parser
would terminate the current statement and start a new one. As more key
words were added, this became harder to do until now there are a few
statements which start with keywords that aren't recognized as starting a
statement (SEND, RECEIVE, WITH, etc.) so a semi-colon is required to
separate the statements. Long term, there will probably be a requirement to
use statement separators at some point. You may (or may not) have noticed
that all the samples in the doc use semi-colon terminators as a way to get
you started thinking that way.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Mike C#" <xxx@.yyy.com> wrote in message news:92Ykg.18$uU6.13@.fe08.lga...
> It's an indicator that you've reached the end of the statement. It's
> especially handy when sending SQL statements from a client application,
> where you might have multiple statements in a single string/on a single
> line. I suppose it can also help readability, since it gives you a visual
> cue that you've reached the end of a statement. I don't think it helps
> improve performance (speed) considerably.
> "Senna" <Senna@.discussions.microsoft.com> wrote in message
> news:B9A504EE-8F1F-4048-BF60-16CB2341B9CF@.microsoft.com...
>
No comments:
Post a Comment