Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2005 Forums
 Transact-SQL (2005)
 GO statement

Author  Topic 

CoffeeAddict
Yak Posting Veteran

94 Posts

Posted - 2009-08-05 : 23:21:19
I do not understand what the GO statement is even after reading about it on 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. "

Ok, wtf does that mean, plain english please? This is jibberish. I don't understand batches in sql.

waterduck
Aged Yak Warrior

982 Posts

Posted - 2009-08-05 : 23:25:01
please refer to madhi article...http://sqlblogcasts.com/blogs/madhivanan/archive/tags/GO/default.aspx


Hope can help...but advise to wait pros with confirmation...
Go to Top of Page

waterduck
Aged Yak Warrior

982 Posts

Posted - 2009-08-05 : 23:25:02
please refer to madhi article...http://sqlblogcasts.com/blogs/madhivanan/archive/tags/GO/default.aspx


Hope can help...but advise to wait pros with confirmation...
Go to Top of Page

waterduck
Aged Yak Warrior

982 Posts

Posted - 2009-08-05 : 23:25:30
wow how i did this?


Hope can help...but advise to wait pros with confirmation...
Go to Top of Page

CoffeeAddict
Yak Posting Veteran

94 Posts

Posted - 2009-08-05 : 23:30:54
sorry I'm still not getting this.
Go to Top of Page

waterduck
Aged Yak Warrior

982 Posts

Posted - 2009-08-05 : 23:34:52
[code]DECLARE @tempfun TABLE(col1 INT)
INSERT INTO @tempfun VALUES(1)
SELECT *
FROM @tempfun
GO
SELECT *
FROM @tempfun[/code]
as you execute above query, the second query will not able to compile, this is because after first query, the (session) ended


Hope can help...but advise to wait pros with confirmation...
Go to Top of Page

CoffeeAddict
Yak Posting Veteran

94 Posts

Posted - 2009-08-05 : 23:40:14
why would the second not run? You created the table already so why wouldn't you be able to select * from @tempfun again?
Go to Top of Page

waterduck
Aged Yak Warrior

982 Posts

Posted - 2009-08-05 : 23:47:58
this is because @tempfun is a table variable, it does not save in database actual table and it does not allocate at tempdb too, so when it reach GO section, it will disappear, i think you can assume GO is almost like BREAK but go doesn't BREAK from loop; it just break the whole section...


Hope can help...but advise to wait pros with confirmation...
Go to Top of Page

waterduck
Aged Yak Warrior

982 Posts

Posted - 2009-08-05 : 23:52:00
http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=130609&SearchTerms=GO


Hope can help...but advise to wait pros with confirmation...
Go to Top of Page

CoffeeAddict
Yak Posting Veteran

94 Posts

Posted - 2009-08-06 : 00:04:09
Ok, here's what I don't understand. Why do I need go at all? Lets say we have one big DB script file and developers like me just keep adding new statements to alter the database based on projects we do. Why should I care about go and just paste in my statements that should be deployed to production?
Go to Top of Page

waterduck
Aged Yak Warrior

982 Posts

Posted - 2009-08-06 : 01:23:20
sorry..i went for lunch just now...and take mini nap...you can play GO like loop...as madhi show in the article he wrote


Hope can help...but advise to wait pros with confirmation...
Go to Top of Page

madhivanan
Premature Yak Congratulator

22864 Posts

Posted - 2009-08-06 : 02:39:16
Well. You have bunch of queries in the query analyser and you want to execute them simultaneously. If your code has CREATE/ALTER procedure or any ddl statements, they should be followed by GO

ex

Run this and see you will get an error

Create table #t(i int)
insert into #t(i)
select 34
select i from #t
alter table #t add j int
insert into #t(i,j)
select 23,74
select i,j from #t

Now run this and you wont get error

drop table #t
GO
Create table #t(i int)
insert into #t(i)
select 34
select i from #t
alter table #t add j int
GO
insert into #t(i,j)
select 23,74
select i,j from #t

Madhivanan

Failing to plan is Planning to fail
Go to Top of Page

CoffeeAddict
Yak Posting Veteran

94 Posts

Posted - 2009-08-06 : 21:53:30
thanks, I'll try that out.
Go to Top of Page

Dobe
Starting Member

12 Posts

Posted - 2009-08-07 : 10:38:54
GO is like a reset button. In some cases, you can't run certain routines unless prior code has built or altered objects for that code. Make sense?
So build or alter an object...reset (GO)...object built or altered...additional code.
Go to Top of Page

dba123
Yak Posting Veteran

90 Posts

Posted - 2009-08-11 : 11:33:43
got it.
Go to Top of Page

X002548
Not Just a Number

15586 Posts

Posted - 2009-08-11 : 12:15:02
oye

GO

Is like an implicit COMMIT



Brett

8-)

Hint: Want your questions answered fast? Follow the direction in this link
http://weblogs.sqlteam.com/brettk/archive/2005/05/25/5276.aspx

Add yourself!
http://www.frappr.com/sqlteam



Go to Top of Page

CoffeeAddict
Yak Posting Veteran

94 Posts

Posted - 2009-08-12 : 10:48:55
implicit COMMIT

not following you. What is a commit.

quote:
Originally posted by X002548

oye

GO

Is like an implicit COMMIT



Brett

8-)

Hint: Want your questions answered fast? Follow the direction in this link
http://weblogs.sqlteam.com/brettk/archive/2005/05/25/5276.aspx

Add yourself!
http://www.frappr.com/sqlteam





Go to Top of Page

Transact Charlie
Master Smack Fu Yak Hacker

3451 Posts

Posted - 2009-08-12 : 11:12:02
quote:
implicit COMMIT

not following you. What is a commit.


I assume you are completely new to this.

Every action in SQL server takes place inside something called a TRANSACTION. TRANSACTIONS are only written to the database when the COMMIT statement is issued. They can be ROLLBACK'd so that no actual changes are performed instead. I take it you have just been using management studio or whatever and executing queries? In this case the TRANSACTION in invisible and is implicitly COMMITTED. Also under this condition each individual TRANSACT SQL STATEMENT will be committed immediately upon successful completion.

Each individual SQL statement in SQL Server is ATOMIC. What that means is that all of the statement will be completed or none of it will.

For example if you issue
UPDATE foo SET [bar] = 1

(where foo is a table with 10 million records in it) then the update statement will either fail (no rows will be changed) or will set them all (10 million rows will be changed) there is no condition where it can get stuck 'Half - way' Hence it is ATOMIC (all or nothing)

The way that SQL Server guarantees this is through TRANSACTIONS.

Try this code for example:

BEGIN TRANSACTION

CREATE TABLE #foo (
[Id] INT
, [val] NVARCHAR(255)
)

INSERT #foo ([Id], [val])
SELECT 1, 'a'
UNION SELECT 2, 'b'

SELECT * FROM #foo

ROLLBACK TRANSACTION

SELECT * FROM #foo




Charlie
===============================================================
Msg 3903, Level 16, State 1, Line 1736
The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION
Go to Top of Page

CoffeeAddict
Yak Posting Veteran

94 Posts

Posted - 2009-08-12 : 11:14:07
I know about transaction scope. I just don't code in SQL every day, especially with transaction syntax. I am a C# programmer and try to stay away from SQL as much as possible. I work with triggers, procs, etc. but I am not heavy into SQL syntax for commits or transaction scope. I mostly work with that in C#.
Go to Top of Page

CoffeeAddict
Yak Posting Veteran

94 Posts

Posted - 2009-08-12 : 11:15:24
>>>TRANSACTION in invisible and is implicitly COMMITTED

so it's not that I have never seen rollback syntax. I just don't use it a lot. and implicitly committed is exactly why I did not understand when you simply said COMMIT. There's a lot more behind your initial sentence and inferred information that you posted after.
Go to Top of Page

Transact Charlie
Master Smack Fu Yak Hacker

3451 Posts

Posted - 2009-08-12 : 11:16:10
From BOL (books On Line)

quote:


A transaction is a sequence of operations performed as a single logical unit of work. A logical unit of work must exhibit four properties, called the atomicity, consistency, isolation, and durability (ACID) properties, to qualify as a transaction.

Atomicity
A transaction must be an atomic unit of work; either all of its data modifications are performed, or none of them is performed.

Consistency
When completed, a transaction must leave all data in a consistent state. In a relational database, all rules must be applied to the transaction's modifications to maintain all data integrity. All internal data structures, such as B-tree indexes or doubly-linked lists, must be correct at the end of the transaction.

Isolation
Modifications made by concurrent transactions must be isolated from the modifications made by any other concurrent transactions. A transaction either recognizes data in the state it was in before another concurrent transaction modified it, or it recognizes the data after the second transaction has completed, but it does not recognize an intermediate state. This is referred to as serializability because it results in the ability to reload the starting data and replay a series of transactions to end up with the data in the same state it was in after the original transactions were performed.

Durability
After a transaction has completed, its effects are permanently in place in the system. The modifications persist even in the event of a system failure.

Specifying and Enforcing Transactions
SQL programmers are responsible for starting and ending transactions at points that enforce the logical consistency of the data. The programmer must define the sequence of data modifications that leave the data in a consistent state relative to the organization's business rules. The programmer includes these modification statements in a single transaction so that the SQL Server 2005 Database Engine can enforce the physical integrity of the transaction.

It is the responsibility of an enterprise database system, such as an instance of the Database Engine, to provide mechanisms ensuring the physical integrity of each transaction. The Database Engine provides:

Locking facilities that preserve transaction isolation.


Logging facilities that ensure transaction durability. Even if the server hardware, operating system, or the instance of the Database Engine itself fails, the instance uses the transaction logs upon restart to automatically roll back any uncompleted transactions to the point of the system failure.


Transaction management features that enforce transaction atomicity and consistency. After a transaction has started, it must be successfully completed, or the instance of the Database Engine undoes all of the data modifications made since the transaction started.




Charlie
===============================================================
Msg 3903, Level 16, State 1, Line 1736
The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION
Go to Top of Page
    Next Page

- Advertisement -