Printable View
I've read that Undo is better that using confirmation dialogs, just wanted to know to what extent should we undo when performing database manipulations, is once enough already? For instance if I added a new record then updated another one, would I extend the undo such that the first process (adding a new record) would be "undo'd" (I can't find the correct term!) or to be able to undo the latest process would be just fine? And is it advisable to incorporate Redo in such cases?
"undone" ;)
Personally as a user I like a selectable level of undo. As much as possible, seeing as I tend to screw things up :)
Say a user-selectable value of between 1 and 100 undo levels, maybe?
In a database system - with multiple users hitting that database - I do not believe that "undo" has a valid purpose.
So my vote is none! ;)
From szlamany
I would definately agree with that. If the user makes a mistake and they realise that thriy minites later and someone else has changed data? What goes back? The user is responsible for thier actions. The DBA might be able to recover the probelm using log files and that should be the only Undo or Redo in a multi-user database system. I've programed some large Navy apps (from the Oracle DBA side I might as well confess not the app programmer). But either they live with the conformation or live with OOPS I $#$$#$ up please save my butt the Lorad God DBA.Quote:
In a database system - with multiple users hitting that database - I do not believe that "undo" has a valid purpose.
So my vote is none!
I've read somewhere that using Undo is divine while confirmation is evil (something like that), though you guys (sz and Gary) have strong points, I guess I'll have to live with the confirmation thingy... :)
UNDO breaks the DURABILITY part of the ACID test.
DURABILITY - after a transaction is completed, it effects are permanently in place in the system.
Here's the article, I guess it won't apply to database operations am I right?