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.
| 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 |
|
|
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 forBEGIN TRANSACTIONInsert SomethingIF ERROR GOTO ABORTInsert something elseIF ERROR GOTO ABORTCOMMITGOTO DONEABORT:ROLLBACKDONE: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 |
 |
|
|
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. |
 |
|
|
spider3
Starting Member
11 Posts |
Posted - 2007-07-12 : 04:49:20
|
| Thank you everyone for your suggestions, now I got the points *smile* |
 |
|
|
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 |
 |
|
|
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 1980blog: http://weblogs.sqlteam.com/mladenp |
 |
|
|
|
|
|
|
|