Re: GO ...?

Hi Hugo,

Your resonse was very helpful. Thank you. So it seems GO is purely a
client side command, which makes sense. If client doesn't support GO, then
it is a non-issue.
But even inside QA (or 2005 query pane), without GO, is there ever a danger
in sql server not processing code sequentially (i.e., processing a subsequent
line prior to completely processing a prior line)? I have never run into
that problem.

Assuming I want my 300 lines of code (test for temp table existence > create
temp tables > do table joins and insert temp table data > update temp table
data > return results) to run top to bottom, sequentially, is there a
necessity for GO? I know I can use it, but is it ever a requirement to make
script run right? Assume variable scope is not an issue.

Thanks again for you help ...

Bill



"Hugo Kornelis" wrote:

On Sat, 22 Aug 2009 07:24:01 -0700, WCM wrote:

Hi Andrew,

Thanks for your reply.

I don't use GO statements as I have always assumed sql server will process
my T-Sql one line at a time, and it will finish processing that line before
moving on to the next. In other words, if my #temp table 'create table'
statement appears before my 'insert' statement, sql server will always create
the table before executing the 'insert' statement. And if my 'update'
statement appears after the 'insert statement', sql server will always insert
all data before executing the 'update'. I have never run into a problem with
this assumption.

Am I missing something? As long as my code is sequentially logical, should
I be concerned with processing it all as one 'batch' (i.e., with no GO
statement)?

Also, one of my clients uses ColdFusion with sql server backend. I don't
believe GO statements are allowed in ColdFusion pass through queries.

Thanks again for your clarification ... much appreciated.

Hi Bill,

To cllarify, GO is not a SQL statement. It is a special code, recognised
by most front end clients, to signify the end of the batch. In other
words, GO means to the front end: "Stop here, and send the commands up
till now to the server. Only start submitting the next batch after the
server returns from this one". If you use a client that doesn't use the
GO terminator, and you still embed it in your code, you'll get syntax
errors as SQL Server itself doesn;t recognise it as a valid keyword.

There are cases where you need to seperate your code in batches. For
instance, a CREATE PROCEDURE statement must be the first in a batch, and
everything that follows it until the end of the batch is interpreted as
being part of that procedure, so if you need to do more actions after
creating the procedure, you need a batch seperator.

On the other hand, there are also cases where you must not put commands
into seperate batches. Variable declarations always last until the end
of the batch, so if you put a GO between the variable declaration and
the use of that variable, you'll get an error in the second batch
because the variable is no longer declared.

I hope this helps.

--
Hugo Kornelis, SQL Server MVP
My SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis

.

Relevant Pages

  • Re: Precompiling checking problem
    ... GO is a batch separator for the client, it is not a SQL statement. ... SQL Server MVP ...
    (microsoft.public.sqlserver.tools)
  • Re: Concurrency problem
    ... Is it okay if the client application view the data while only part of the batch has completed making changes? ... Is it importing data using ADO UPDATE/INSERT commands or is it using BCP/SSIS/SqlBulkCopy to import the data and a server-side procedure to integrate it into the database? ... Hitchhiker's Guide to Visual Studio and SQL Server ...
    (microsoft.public.dotnet.framework.adonet)
  • Optimization of large update batches; high "Reads" value in profiler?
    ... I am using batches with about 1000 commands per ... I am processing up to 20.000 such updates per minute, ... method in SQL Server 2005. ... For example a batch of 1000 updates ...
    (microsoft.public.sqlserver)
  • Reading batches of records for a form
    ... I have a form to show transaction data from an SQL server. ... large number of records for a client. ... rereading the next batch of data each time? ...
    (microsoft.public.access.forms)
  • Re: Access 2007->SQL Server2005 "connection was forcibly closed",G
    ... I think it will ameliorate the situation if you clean up the client as ... And to come back to my problem: I think with help of the SQL Server admins ... closed connections - but all of these errors are in the version which used ... Every new client opens again 30 connections if I open 30 tables ...
    (microsoft.public.sqlserver.connect)
Loading