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
 General SQL Server Forums
 New to SQL Server Programming
 How can I move data from Table

Author  Topic 

jooorj
Posting Yak Master

126 Posts

Posted - 2011-04-10 : 18:14:06
How can I move data from Table to another table using one statement Only ?
and the original table have to remove with data.
exactly make cut & paste.
thanks

tkizer
Almighty SQL Goddess

38200 Posts

Posted - 2011-04-10 : 18:21:40
You can use INSERT INTO/SELECT.

INSERT INTO Table1 (...)
SELECT ...
FROM Table2

Tara Kizer
Microsoft MVP for Windows Server System - SQL Server
http://weblogs.sqlteam.com/tarad/

Subscribe to my blog
Go to Top of Page

tkizer
Almighty SQL Goddess

38200 Posts

Posted - 2011-04-10 : 18:55:50
You edited your reply several minutes after my post, here's to answer the edit:

DROP TABLE Table2

SELECT *
INTO Table2
FROM Table1

Or:

TRUNCATE TABLE Table2/DELETE FROM Tabl2

Then use INSERT INTO/SELECT.

Tara Kizer
Microsoft MVP for Windows Server System - SQL Server
http://weblogs.sqlteam.com/tarad/

Subscribe to my blog
Go to Top of Page

jooorj
Posting Yak Master

126 Posts

Posted - 2011-04-10 : 19:03:48
but in One statement ! I need
Go to Top of Page

tkizer
Almighty SQL Goddess

38200 Posts

Posted - 2011-04-10 : 19:07:34
If you want to remove rows and then add rows, you'll need two statements. If there are rows that are exactly the same in both, then you can use one statement. So let us know what you have plus what version of SQL you are using.

Tara Kizer
Microsoft MVP for Windows Server System - SQL Server
http://weblogs.sqlteam.com/tarad/

Subscribe to my blog
Go to Top of Page

khtan
In (Som, Ni, Yak)

17689 Posts

Posted - 2011-04-10 : 21:05:33
quote:
Originally posted by jooorj

but in One statement ! I need



Why ? What's wrong with doing it in 2 separate statement ?


KH
[spoiler]Time is always against us[/spoiler]

Go to Top of Page

jooorj
Posting Yak Master

126 Posts

Posted - 2011-04-23 : 11:21:22
I think must use merge
Go to Top of Page

GilaMonster
Master Smack Fu Yak Hacker

4507 Posts

Posted - 2011-04-23 : 12:46:44
Err, why?

Merge is for doing an 'upsert', combination of insert, update and delete on one table. It is not going to do what you asked, move data from one table to another. That will require two statements, one to insert into the destination, one to delete the inserted rows from the source.

Why do you want one statement?

--
Gail Shaw
SQL Server MVP
Go to Top of Page

sunitabeck
Master Smack Fu Yak Hacker

5155 Posts

Posted - 2011-04-23 : 13:53:00
Joorg, if you are concerned that the operation will not be atomic -
that you would delete the data and may not have saved into the target table,
you can wrap the delete and insert into a transaction.
That would guarantee that either both operations succeed, or neither operation is performed.It would be something like this

begin tran
insert into yourTargetTable select col1,col2..coln from yourSourceTable;
delete from yourSourceTable
commit tran
If you must do it in one statement then use OUTPUT
clause. No need to start an explicit transaction in this case,
but you have to be on SQL 2005 or higher. The syntax is

delete from yourSourceTable
output deleted.col1, deleted.col2,...,deleted.colN into yourTargetTable
Go to Top of Page

GilaMonster
Master Smack Fu Yak Hacker

4507 Posts

Posted - 2011-04-23 : 14:19:37
Just note that the OUTPUT ... INTO <permanent table> is SQL 2008+ only.

quote:
you can wrap the delete and insert into a transaction.
That would guarantee that either both operations succeed, or neither operation is performed.It would be something like this

begin tran
insert into yourTargetTable select col1,col2..coln from yourSourceTable;
delete from yourSourceTable
commit tran


With that code, the insert could fail, the delete succeed and the transaction commit. It both or neither is required, error handling is needed.

Simplified code:

begin try
begin transaction
insert into yourTargetTable select col1,col2..coln from yourSourceTable;
delete from yourSourceTable
commit transaction
end try
begin catch
rollback transaction
end catch


--
Gail Shaw
SQL Server MVP
Go to Top of Page

sunitabeck
Master Smack Fu Yak Hacker

5155 Posts

Posted - 2011-04-23 : 14:55:24
I could have sworn that the output feature was part of SQL 2005. On my SQL 2005 SP2, it does seem to work.

create table dbo.TA (id int);
create table dbo.TB (id int);

insert into TA values (1);
insert into TA values (2);
insert into TA values (3);

delete from TA
output deleted.id into TB
where id > 2;

select * from TB;

drop table TA;
drop table TB;


Edit: my version is 9.00.1399.06, Build 2600, Service Pack 2.
Go to Top of Page

sunitabeck
Master Smack Fu Yak Hacker

5155 Posts

Posted - 2011-04-23 : 15:02:29
quote:
Originally posted by GilaMonster

Just note that the OUTPUT ... INTO <permanent table> is SQL 2008+ only.

quote:
you can wrap the delete and insert into a transaction.
That would guarantee that either both operations succeed, or neither operation is performed.It would be something like this

begin tran
insert into yourTargetTable select col1,col2..coln from yourSourceTable;
delete from yourSourceTable
commit tran


With that code, the insert could fail, the delete succeed and the transaction commit. It both or neither is required, error handling is needed.

Simplified code:

begin try
begin transaction
insert into yourTargetTable select col1,col2..coln from yourSourceTable;
delete from yourSourceTable
commit transaction
end try
begin catch
rollback transaction
end catch


--
Gail Shaw
SQL Server MVP


Thanks for that Gail. Certainly, wrap the query in a try/catch block. If you don't, I think the risk is not that the first statement will be committed and the second won't; rather it is that the transaction will be left open indefinitely, and Jooorg will be scrathing his head why he can't even do a select from that table!!

If the second statement is going to raise an exception, and if the user code does not catch the exception, it will bubble up to the next level, which in this example would go into SQL's own exception handling.
Go to Top of Page

GilaMonster
Master Smack Fu Yak Hacker

4507 Posts

Posted - 2011-04-23 : 16:14:06
quote:
Originally posted by sunitabeck

If you don't, I think the risk is not that the first statement will be committed and the second won't; rather it is that the transaction will be left open indefinitely, and Jooorg will be scrathing his head why he can't even do a select from that table!!


No, the transaction will commit (unless the connection is terminated in which case it will roll back), but there is nothing that checks whether the operations have succeeded or not.

An error on either of those statements, providing it is not serious enough to terminate the entire connection, will NOT cause the transaction to roll back, nor will it abort the batch. If there's no try-catch, SQL will run each statement and, regardless of whether it succeeds or not, simply go onto the next.

Consider this demo:

 CREATE TABLE #TestingTransactions (
ID INT UNIQUE NOT NULL
);

BEGIN TRANSACTION

INSERT INTO #TestingTransactions (ID)
VALUES (1) -- succeeds

INSERT INTO #TestingTransactions (ID)
VALUES (NULL) -- fails. Null into a not-null column

INSERT INTO #TestingTransactions (ID)
VALUES (2) -- succeeds

INSERT INTO #TestingTransactions (ID)
VALUES (1) -- fails. Unique key violation

INSERT INTO #TestingTransactions (ID)
VALUES (3) -- succeeds

COMMIT TRANSACTION

SELECT * FROM #TestingTransactions


How many rows do you think that select will return?

--
Gail Shaw
SQL Server MVP
Go to Top of Page

GilaMonster
Master Smack Fu Yak Hacker

4507 Posts

Posted - 2011-04-23 : 16:16:21
quote:
Originally posted by sunitabeck

I could have sworn that the output feature was part of SQL 2005. On my SQL 2005 SP2, it does seem to work.


My bad then. I thought on 2005 it was limited to inserting into a table variable

quote:
Edit: my version is 9.00.1399.06, Build 2600, Service Pack 2.


That's RTM of SQL 2005. No service packs. You may want to apply SP4.

--
Gail Shaw
SQL Server MVP
Go to Top of Page

sunitabeck
Master Smack Fu Yak Hacker

5155 Posts

Posted - 2011-04-23 : 16:36:31
quote:
Originally posted by GilaMonster


How many rows do you think that select will return?

--
Gail Shaw
SQL Server MVP


You are absolutely right. It generates the exception, and goes right past the exception to the next statement as though "Meh! what is a silly exception while I have more things to do!!"

This is very different from the .Net world where if an exception thrown, execution stops at that point. Then the control jumps to the catch block if there is one (same in SQL) and, if there is no catch block, bubbles up through the call-stack(different behavior). If there is no user catch block anywhere in the call-stack, it finally ends up in .Net's own catch.
Go to Top of Page

sunitabeck
Master Smack Fu Yak Hacker

5155 Posts

Posted - 2011-04-23 : 16:47:03
quote:
Originally posted by GilaMonster

That's RTM of SQL 2005. No service packs. You may want to apply SP4.

--
Gail Shaw
SQL Server MVP


Thanks Gail. I was looking at my Windows XP version which is SP2 and thought that was the SQL version.
Go to Top of Page

GilaMonster
Master Smack Fu Yak Hacker

4507 Posts

Posted - 2011-04-23 : 17:02:08
quote:
Originally posted by sunitabeck

You are absolutely right. It generates the exception, and goes right past the exception to the next statement as though "Meh! what is a silly exception while I have more things to do!!"

This is very different from the .Net world where if an exception thrown, execution stops at that point.


Yup. SQL's errors are a pain.

There are multiple degrees of errors (which doesn't always match with the value for severity), statement terminating errors (which both of the above are and which many of the common errors are), batch terminating and connection terminating.

Statement-terminating errors will not result in a transaction rollback (unless xact_abort is on) and so must be caught and handled.

At least we have try-catch now.

--
Gail Shaw
SQL Server MVP
Go to Top of Page
   

- Advertisement -