Take the 2-minute tour ×

I am implementing an undo button for a lengthy operation on a web app. Since the undo will come in another request, I have to commit the operation.

Is there a way to issue a hint on the transaction like "maybe rollback"? So after the transaction is committed, I could still rollback in another processes if needed.

Otherwise the Undo function will be as complex as the operation it is undoing.

Is this possible? Other ideas welcome!

share|improve this question
Will there be data dependencies on the information you've committed? –  Paul Nathan Nov 6 '09 at 21:31
Only with foreign keys and child data. Those should be deleted too of course. but the operation is atomic and a rollback would safely do the right thing. –  Byron Whitlock Nov 6 '09 at 21:34
add comment

3 Answers

up vote 4 down vote accepted

The idea in this case is to log for each operation - a counter operation that do the opposite, in a special log and when you need to rollback you actually run the commands that you've logged.

some databases have flashback technology that you can ask the DB to go back to certain date and time. but you need to understand how it works, and make sure it will only effect the data you want and not other staff...

Oracle Flashback

I don't think there is a similar technology on SQL server and there is a SO answer that says it doesn't, but SQL keeps evolving...

share|improve this answer
If the event didn't happen too long ago, you can use tools from Log PI or Apex SQL (Lumigent made a good one but stopped producing it after the log format changes in 2005). Good discussion about this here, including several links to articles about doing it natively (assuming a good backup): developersdex.com/sql/message.asp?p=580&r=6497847 Quest LiteSpeed has a good backup inspection feature as well, allowing you to see what the data looked like at the time of the backup. –  Aaron Bertrand Nov 7 '09 at 19:41
ApexSQL Log: apexsql.com/sql_tools_log.asp ... Log PI seems to no longer exist ... Quest LiteSpeed : quest.com/litespeed-for-sql-server –  Aaron Bertrand Nov 7 '09 at 19:45
add comment

Another option you might want to consider: If it's possible for the user to 'undo' the operation, you may want to implement an 'intent' table where you can store pending operations. Once you go through your application flow, the user would need to Accept or Undo the operation, at which point you can just run the pending transaction and apply it to your database.

We have a similar system in place on our web application, where a user can submit a transaction for processing and has until 5pm on the day it's scheduled to run to cancel it. We store this in an intent table and process any transactions scheduled for that day after the daily cutoff time. In your case you would need an explicit 'Accept' or 'Undo' operation from the user after the initial 'lengthy operation', so that would change your process a little bit.

Hope this helps.

share|improve this answer
add comment

I'm not sure what technologies you're using here, but there are certainly better ways of going about this. You could start by storing the data in the session and committing when they are on the final page. Many frameworks these days also allow for long running transactions that span multiple requests.

However, you will probably want to commit at the end of every page and simply set some sort of flag for when the process is completed. That way if something goes wrong in the middle of it the user can recover and all is not lost.

share|improve this answer
add comment

Your Answer


