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
 Rollback transaction with multiple queries?

Author  Topic 

spider3
Starting Member

11 Posts

Posted - 2007-07-10 : 04:15:51
Hi everyone,
I am reading about the Rollback transaction but I'm not sure if it's the feature I need.
My application is going to update a few tables, but my programmer said that it will be done using more than 1 transaction.
For example, if I want to create a new employer with all the detailed informations, tables will be filled when the user complete the insertion of a part of data. If he decides to abort the operation, i'd like to delete all the values inserted before with the other queries. Is it possible to create a "savepoint" and roll back all transactions processed from this savepoint?

thank you!

sachinsamuel
Constraint Violating Yak Guru

383 Posts

Posted - 2007-07-10 : 04:52:39
Yes its very much possible. Please check "Save Transaction" in books online or check

http://technet.microsoft.com/en-us/library/ms188378.aspx






Don't sit back because of failure. It will come back to check if you still available. -- Binu
Go to Top of Page

Kristen
Test

22859 Posts

Posted - 2007-07-10 : 05:14:26
"If he decides to abort the operation"

You ought not to have a transaction whilst the user decides something.

More normally a transaction is used for

BEGIN TRANSACTION
Insert Something
IF ERROR GOTO ABORT
Insert something else
IF ERROR GOTO ABORT
COMMIT
GOTO DONE

ABORT:
ROLLBACK

DONE:

The general idea is that once the user has provided all the New Employer data AND all the Detailed Information, then using a Transaction ALL the data will be inserted OR NONE of it - rather than just PART of the data being inserted [and then an error preventing the rest from being inserted]

Kristen
Go to Top of Page

LoztInSpace
Aged Yak Warrior

940 Posts

Posted - 2007-07-11 : 03:13:07
Spider3 - I think you're a little bit off the mark here. Transactions are defined by business requirements. Not programmers, not user interfaces and not by the availability (or otherwise) of a particular technology.
You need to take a look at what the rules are and make sure your programmer implements it. If the requirement is all or nothing then you must make him to do that. If you go a "manual transaction" path (not recommended if it's avoidable) you need to consider what happens if the system goes down between operations as Kristen says. Basically you will be replicating a lot of what the database can already do if you do it properly.
So in summary, from what I can tell, what you are talking about is simply identifying transactions and writing code to deal with when those transactions already committed are no longer required. This is virtually the same as any other system. Don't let your programmer bully you into letting him implement a half-arsed system.
Go to Top of Page

spider3
Starting Member

11 Posts

Posted - 2007-07-12 : 04:49:20
Thank you everyone for your suggestions, now I got the points *smile*
Go to Top of Page

NarayanaMoorthy
Starting Member

19 Posts

Posted - 2007-07-13 : 09:46:53
hai, i am an tyro in sql. can anyone help me to sort out this problem.
why we are going for views instead of select statement.

NarayanaMoorthy
Go to Top of Page

spirit1
Cybernetic Yak Master

11752 Posts

Posted - 2007-07-13 : 09:49:06
create a new thread for your question. don't use existing thread from other people.

views are just stored select statements.

_______________________________________________
Causing trouble since 1980
blog: http://weblogs.sqlteam.com/mladenp
Go to Top of Page
   

- Advertisement -