|
database
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
|
Greetings,
I am looking for a way to implement UNDO in my database apps. We have several SQL 2005 Standard Ed and SQL Everywhere database apps. Some are connected to web forms and a few others connect to Windows forms. What I would like to do is give users a command to UNDO some number of their most recent changes. Like most db apps, a single form submit can change numerous tables in the db in one go. Is there a way to create an UNDO stack? How do you elegantly code selective UNDO's? If you could point me to good learning resources for this, I would be grateful. Thanks. Your best bet is to not execute commands on the database, and instead cache
the changes in the application. When the user is ready to save, then issue the commands to the database. If they want to "UNDO" you simply remove those particular commands from the application. Show quote "catsailor" <hullflyer at gmail.com> wrote in message news:dc09d$45097a07$48f535c4$31889@msgid.meganewsservers.com... > Greetings, > I am looking for a way to implement UNDO in my database apps. We have > several SQL 2005 Standard Ed and SQL Everywhere database apps. Some are > connected to web forms and a few others connect to Windows forms. What I > would like to do is give users a command to UNDO some number of their most > recent changes. Like most db apps, a single form submit can change numerous > tables in the db in one go. Is there a way to create an UNDO stack? How do > you elegantly code selective UNDO's? > > If you could point me to good learning resources for this, I would be > grateful. Thanks. > > I whole-heartedly agree with Jim. However, you could create an "Audit"
table. This would be populated by a trigger with all of the old values. You could create an UNDO process where you update the live table with the values for that transaction in the Audit table. Still, Jim is right. It is best to write it into your app and insert the new data only when you are sure. Jim Underwood wrote: Show quote > Your best bet is to not execute commands on the database, and instead cache > the changes in the application. When the user is ready to save, then issue > the commands to the database. If they want to "UNDO" you simply remove > those particular commands from the application. > > "catsailor" <hullflyer at gmail.com> wrote in message > news:dc09d$45097a07$48f535c4$31889@msgid.meganewsservers.com... > > Greetings, > > I am looking for a way to implement UNDO in my database apps. We have > > several SQL 2005 Standard Ed and SQL Everywhere database apps. Some are > > connected to web forms and a few others connect to Windows forms. What I > > would like to do is give users a command to UNDO some number of their most > > recent changes. Like most db apps, a single form submit can change > numerous > > tables in the db in one go. Is there a way to create an UNDO stack? How > do > > you elegantly code selective UNDO's? > > > > If you could point me to good learning resources for this, I would be > > grateful. Thanks. > > > > In most cases, IF an audit table is alterable at any time, in any manner, by
the users, or their applications, if is no longer an audit table. Most definitely not allowed in HIPPA or SarBox affected databases. -- Arnie Rowland, Ph.D. Westwood Consulting, Inc Most good judgment comes from experience. Most experience comes from bad judgment. - Anonymous Show quote "Gary Gibbs" <ggi***@aahs.org> wrote in message news:1158251170.170716.311670@h48g2000cwc.googlegroups.com... >I whole-heartedly agree with Jim. However, you could create an "Audit" > table. This would be populated by a trigger with all of the old > values. You could create an UNDO process where you update the live > table with the values for that transaction in the Audit table. > > Still, Jim is right. It is best to write it into your app and insert > the new data only when you are sure. > > > Jim Underwood wrote: >> Your best bet is to not execute commands on the database, and instead >> cache >> the changes in the application. When the user is ready to save, then >> issue >> the commands to the database. If they want to "UNDO" you simply remove >> those particular commands from the application. >> >> "catsailor" <hullflyer at gmail.com> wrote in message >> news:dc09d$45097a07$48f535c4$31889@msgid.meganewsservers.com... >> > Greetings, >> > I am looking for a way to implement UNDO in my database apps. We have >> > several SQL 2005 Standard Ed and SQL Everywhere database apps. Some >> > are >> > connected to web forms and a few others connect to Windows forms. What >> > I >> > would like to do is give users a command to UNDO some number of their >> > most >> > recent changes. Like most db apps, a single form submit can change >> numerous >> > tables in the db in one go. Is there a way to create an UNDO stack? >> > How >> do >> > you elegantly code selective UNDO's? >> > >> > If you could point me to good learning resources for this, I would be >> > grateful. Thanks. >> > >> > > Sorry I was not clear. I was not suggesting that you alter the Audit
table. Rather, use the values in the Audit in an Update statement for the Live table. The trigger for the Live table would add a row to Audit table showing a new update. Arnie Rowland wrote: Show quote > In most cases, IF an audit table is alterable at any time, in any manner, by > the users, or their applications, if is no longer an audit table. > > Most definitely not allowed in HIPPA or SarBox affected databases. > > -- > Arnie Rowland, Ph.D. > Westwood Consulting, Inc > > Most good judgment comes from experience. > Most experience comes from bad judgment. > - Anonymous > > > "Gary Gibbs" <ggi***@aahs.org> wrote in message > news:1158251170.170716.311670@h48g2000cwc.googlegroups.com... > >I whole-heartedly agree with Jim. However, you could create an "Audit" > > table. This would be populated by a trigger with all of the old > > values. You could create an UNDO process where you update the live > > table with the values for that transaction in the Audit table. > > > > Still, Jim is right. It is best to write it into your app and insert > > the new data only when you are sure. > > > > > > Jim Underwood wrote: > >> Your best bet is to not execute commands on the database, and instead > >> cache > >> the changes in the application. When the user is ready to save, then > >> issue > >> the commands to the database. If they want to "UNDO" you simply remove > >> those particular commands from the application. > >> > >> "catsailor" <hullflyer at gmail.com> wrote in message > >> news:dc09d$45097a07$48f535c4$31889@msgid.meganewsservers.com... > >> > Greetings, > >> > I am looking for a way to implement UNDO in my database apps. We have > >> > several SQL 2005 Standard Ed and SQL Everywhere database apps. Some > >> > are > >> > connected to web forms and a few others connect to Windows forms. What > >> > I > >> > would like to do is give users a command to UNDO some number of their > >> > most > >> > recent changes. Like most db apps, a single form submit can change > >> numerous > >> > tables in the db in one go. Is there a way to create an UNDO stack? > >> > How > >> do > >> > you elegantly code selective UNDO's? > >> > > >> > If you could point me to good learning resources for this, I would be > >> > grateful. Thanks. > >> > > >> > > > Many Thanks Gents,
I'll do the confirm-commit for the Windows forms. I would love to have the web apps store data and commit later, but most are step-wise forms apps, kind of like a QuickBooks interview over the web. So, you make changes in one form, move on to other web pages and then realize you want to go back and restore to the way it was 20 minutes ago and begin again. Also, if we automatically commit or don't commit when the browser disconnects, either way we'd be in trouble. It's got to be stateless, and I can't see how this can be achieved for browser-based apps. I'm thinking the Audit table might be the way to go for web apps. Is there an example of an Audit table on the web anywhere you know of? SC Show quote "Gary Gibbs" <ggi***@aahs.org> wrote in message news:1158251170.170716.311670@h48g2000cwc.googlegroups.com... >I whole-heartedly agree with Jim. However, you could create an "Audit" > table. This would be populated by a trigger with all of the old > values. You could create an UNDO process where you update the live > table with the values for that transaction in the Audit table. > > Still, Jim is right. It is best to write it into your app and insert > the new data only when you are sure. > > > Jim Underwood wrote: >> Your best bet is to not execute commands on the database, and instead >> cache >> the changes in the application. When the user is ready to save, then >> issue >> the commands to the database. If they want to "UNDO" you simply remove >> those particular commands from the application. >> >> "catsailor" <hullflyer at gmail.com> wrote in message >> news:dc09d$45097a07$48f535c4$31889@msgid.meganewsservers.com... >> > Greetings, >> > I am looking for a way to implement UNDO in my database apps. We have >> > several SQL 2005 Standard Ed and SQL Everywhere database apps. Some >> > are >> > connected to web forms and a few others connect to Windows forms. What >> > I >> > would like to do is give users a command to UNDO some number of their >> > most >> > recent changes. Like most db apps, a single form submit can change >> numerous >> > tables in the db in one go. Is there a way to create an UNDO stack? >> > How >> do >> > you elegantly code selective UNDO's? >> > >> > If you could point me to good learning resources for this, I would be >> > grateful. Thanks. >> > >> > > One simple approach to audit tables is to have them store the user ID,
timestamp of the change, and the old values of every column that changed, for every table you are auditing. Another approach is to have a seperate row for every column that changed, showing the before and after value, along with the user ID and timestamp. In order to know which transaction performed the change, so you can "undo" it, you would also need a transaction ID on this table. Or, maybe a table with the transaction ID, timestamp, and userid only, and a seperate table that tracks the before and after column values with transaction ID as a foreign key. Keep in mind that before undoing anything, you have to make sure that no one else updated that data since the action you are trying to undo. This can be a very dangerous operation as far as data integrity goes, and you may want to re-consider doing it at all. Show quote "catsailor" <hullflyer at gmail.com> wrote in message news:35df7$45098ad2$48f535c4$32287@msgid.meganewsservers.com... > Many Thanks Gents, > I'll do the confirm-commit for the Windows forms. I would love to have the > web apps store data and commit later, but most are step-wise forms apps, > kind of like a QuickBooks interview over the web. So, you make changes in > one form, move on to other web pages and then realize you want to go back > and restore to the way it was 20 minutes ago and begin again. Also, if we > automatically commit or don't commit when the browser disconnects, either > way we'd be in trouble. It's got to be stateless, and I can't see how this > can be achieved for browser-based apps. I'm thinking the Audit table might > be the way to go for web apps. Is there an example of an Audit table on the > web anywhere you know of? > > SC > > "Gary Gibbs" <ggi***@aahs.org> wrote in message > news:1158251170.170716.311670@h48g2000cwc.googlegroups.com... > >I whole-heartedly agree with Jim. However, you could create an "Audit" > > table. This would be populated by a trigger with all of the old > > values. You could create an UNDO process where you update the live > > table with the values for that transaction in the Audit table. > > > > Still, Jim is right. It is best to write it into your app and insert > > the new data only when you are sure. > > > > > > Jim Underwood wrote: > >> Your best bet is to not execute commands on the database, and instead > >> cache > >> the changes in the application. When the user is ready to save, then > >> issue > >> the commands to the database. If they want to "UNDO" you simply remove > >> those particular commands from the application. > >> > >> "catsailor" <hullflyer at gmail.com> wrote in message > >> news:dc09d$45097a07$48f535c4$31889@msgid.meganewsservers.com... > >> > Greetings, > >> > I am looking for a way to implement UNDO in my database apps. We have > >> > several SQL 2005 Standard Ed and SQL Everywhere database apps. Some > >> > are > >> > connected to web forms and a few others connect to Windows forms. What > >> > I > >> > would like to do is give users a command to UNDO some number of their > >> > most > >> > recent changes. Like most db apps, a single form submit can change > >> numerous > >> > tables in the db in one go. Is there a way to create an UNDO stack? > >> > How > >> do > >> > you elegantly code selective UNDO's? > >> > > >> > If you could point me to good learning resources for this, I would be > >> > grateful. Thanks. > >> > > >> > > > > > > Keep in mind that before undoing anything, you have to make sure that no one Very good points, Jim. Also, consider that some other piece of information was modified, where the > else updated that data since the action you are trying to undo. > > This can be a very dangerous operation as far as data integrity goes, and > you may want to re-consider doing it at all. modification was based on this information. Undo this information can invalidate the other modification. I.e., data integrity is at risk, unless you are very careful and know how the apps interact with the data. -- Tibor Karaszi, SQL Server MVP http://www.karaszi.com/sqlserver/default.asp http://www.solidqualitylearning.com/ Show quote "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message news:udnrlDC2GHA.4176@TK2MSFTNGP06.phx.gbl... > One simple approach to audit tables is to have them store the user ID, > timestamp of the change, and the old values of every column that changed, > for every table you are auditing. > > Another approach is to have a seperate row for every column that changed, > showing the before and after value, along with the user ID and timestamp. > In order to know which transaction performed the change, so you can "undo" > it, you would also need a transaction ID on this table. Or, maybe a table > with the transaction ID, timestamp, and userid only, and a seperate table > that tracks the before and after column values with transaction ID as a > foreign key. > > Keep in mind that before undoing anything, you have to make sure that no one > else updated that data since the action you are trying to undo. > > This can be a very dangerous operation as far as data integrity goes, and > you may want to re-consider doing it at all. > > "catsailor" <hullflyer at gmail.com> wrote in message > news:35df7$45098ad2$48f535c4$32287@msgid.meganewsservers.com... >> Many Thanks Gents, >> I'll do the confirm-commit for the Windows forms. I would love to have > the >> web apps store data and commit later, but most are step-wise forms apps, >> kind of like a QuickBooks interview over the web. So, you make changes in >> one form, move on to other web pages and then realize you want to go back >> and restore to the way it was 20 minutes ago and begin again. Also, if we >> automatically commit or don't commit when the browser disconnects, either >> way we'd be in trouble. It's got to be stateless, and I can't see how > this >> can be achieved for browser-based apps. I'm thinking the Audit table > might >> be the way to go for web apps. Is there an example of an Audit table on > the >> web anywhere you know of? >> >> SC >> >> "Gary Gibbs" <ggi***@aahs.org> wrote in message >> news:1158251170.170716.311670@h48g2000cwc.googlegroups.com... >> >I whole-heartedly agree with Jim. However, you could create an "Audit" >> > table. This would be populated by a trigger with all of the old >> > values. You could create an UNDO process where you update the live >> > table with the values for that transaction in the Audit table. >> > >> > Still, Jim is right. It is best to write it into your app and insert >> > the new data only when you are sure. >> > >> > >> > Jim Underwood wrote: >> >> Your best bet is to not execute commands on the database, and instead >> >> cache >> >> the changes in the application. When the user is ready to save, then >> >> issue >> >> the commands to the database. If they want to "UNDO" you simply remove >> >> those particular commands from the application. >> >> >> >> "catsailor" <hullflyer at gmail.com> wrote in message >> >> news:dc09d$45097a07$48f535c4$31889@msgid.meganewsservers.com... >> >> > Greetings, >> >> > I am looking for a way to implement UNDO in my database apps. We > have >> >> > several SQL 2005 Standard Ed and SQL Everywhere database apps. Some >> >> > are >> >> > connected to web forms and a few others connect to Windows forms. > What >> >> > I >> >> > would like to do is give users a command to UNDO some number of their >> >> > most >> >> > recent changes. Like most db apps, a single form submit can change >> >> numerous >> >> > tables in the db in one go. Is there a way to create an UNDO stack? >> >> > How >> >> do >> >> > you elegantly code selective UNDO's? >> >> > >> >> > If you could point me to good learning resources for this, I would be >> >> > grateful. Thanks. >> >> > >> >> > >> > >> >> > > I'm sure there is but I am not aware of it. Check out BOL about
triggers. On inserts and updates to your live table have it insert a new row of data into the audit table. You will want to track the old values and the new values as well as a timestamp and the user. As it properly warned against earlier, do not allow update rights to ANYONE for any reason. The Audit table is will give you an accurate history of your app. Good Luck catsailor wrote: Show quote > Many Thanks Gents, > I'll do the confirm-commit for the Windows forms. I would love to have the > web apps store data and commit later, but most are step-wise forms apps, > kind of like a QuickBooks interview over the web. So, you make changes in > one form, move on to other web pages and then realize you want to go back > and restore to the way it was 20 minutes ago and begin again. Also, if we > automatically commit or don't commit when the browser disconnects, either > way we'd be in trouble. It's got to be stateless, and I can't see how this > can be achieved for browser-based apps. I'm thinking the Audit table might > be the way to go for web apps. Is there an example of an Audit table on the > web anywhere you know of? > > SC > > "Gary Gibbs" <ggi***@aahs.org> wrote in message > news:1158251170.170716.311670@h48g2000cwc.googlegroups.com... > >I whole-heartedly agree with Jim. However, you could create an "Audit" > > table. This would be populated by a trigger with all of the old > > values. You could create an UNDO process where you update the live > > table with the values for that transaction in the Audit table. > > > > Still, Jim is right. It is best to write it into your app and insert > > the new data only when you are sure. > > > > > > Jim Underwood wrote: > >> Your best bet is to not execute commands on the database, and instead > >> cache > >> the changes in the application. When the user is ready to save, then > >> issue > >> the commands to the database. If they want to "UNDO" you simply remove > >> those particular commands from the application. > >> > >> "catsailor" <hullflyer at gmail.com> wrote in message > >> news:dc09d$45097a07$48f535c4$31889@msgid.meganewsservers.com... > >> > Greetings, > >> > I am looking for a way to implement UNDO in my database apps. We have > >> > several SQL 2005 Standard Ed and SQL Everywhere database apps. Some > >> > are > >> > connected to web forms and a few others connect to Windows forms. What > >> > I > >> > would like to do is give users a command to UNDO some number of their > >> > most > >> > recent changes. Like most db apps, a single form submit can change > >> numerous > >> > tables in the db in one go. Is there a way to create an UNDO stack? > >> > How > >> do > >> > you elegantly code selective UNDO's? > >> > > >> > If you could point me to good learning resources for this, I would be > >> > grateful. Thanks. > >> > > >> > > > It seems that parallel table(s) may be in order. One set for 'work in
progress', and the other for the finished 'committed' state. Interim work is placed in the 'Work in Progress' table(s), then to be committed, it is moved to the production table(s). There could be a scheduled job that regularly purges the 'work in progress' table(s) of abandoned rows. As Jim indicated, it will get real dicey if you allow 'undos' on production data -especially when other users are being impacted, decisions affecting other users are being made on this data that 'may' be undone. Ouch! -- Arnie Rowland, Ph.D. Westwood Consulting, Inc Most good judgment comes from experience. Most experience comes from bad judgment. - Anonymous Show quote "catsailor" <hullflyer at gmail.com> wrote in message news:35df7$45098ad2$48f535c4$32287@msgid.meganewsservers.com... > Many Thanks Gents, > I'll do the confirm-commit for the Windows forms. I would love to have > the web apps store data and commit later, but most are step-wise forms > apps, kind of like a QuickBooks interview over the web. So, you make > changes in one form, move on to other web pages and then realize you want > to go back and restore to the way it was 20 minutes ago and begin again. > Also, if we automatically commit or don't commit when the browser > disconnects, either way we'd be in trouble. It's got to be stateless, and > I can't see how this can be achieved for browser-based apps. I'm thinking > the Audit table might be the way to go for web apps. Is there an example > of an Audit table on the web anywhere you know of? > > SC > > "Gary Gibbs" <ggi***@aahs.org> wrote in message > news:1158251170.170716.311670@h48g2000cwc.googlegroups.com... >>I whole-heartedly agree with Jim. However, you could create an "Audit" >> table. This would be populated by a trigger with all of the old >> values. You could create an UNDO process where you update the live >> table with the values for that transaction in the Audit table. >> >> Still, Jim is right. It is best to write it into your app and insert >> the new data only when you are sure. >> >> >> Jim Underwood wrote: >>> Your best bet is to not execute commands on the database, and instead >>> cache >>> the changes in the application. When the user is ready to save, then >>> issue >>> the commands to the database. If they want to "UNDO" you simply remove >>> those particular commands from the application. >>> >>> "catsailor" <hullflyer at gmail.com> wrote in message >>> news:dc09d$45097a07$48f535c4$31889@msgid.meganewsservers.com... >>> > Greetings, >>> > I am looking for a way to implement UNDO in my database apps. We have >>> > several SQL 2005 Standard Ed and SQL Everywhere database apps. Some >>> > are >>> > connected to web forms and a few others connect to Windows forms. >>> > What I >>> > would like to do is give users a command to UNDO some number of their >>> > most >>> > recent changes. Like most db apps, a single form submit can change >>> numerous >>> > tables in the db in one go. Is there a way to create an UNDO stack? >>> > How >>> do >>> > you elegantly code selective UNDO's? >>> > >>> > If you could point me to good learning resources for this, I would be >>> > grateful. Thanks. >>> > >>> > >> > > Yeow! People have been asking for UNDO, but I didn't think of the
multi-user problems. Some of these are collaborative apps, so more than one user could be working on the database at one time. If I lock the unit a person is working on, it destroys part of the collaborative nature of the tool. If I don't lock it, someone could undo something and corrupt the data relationships. I've got to think about this some more. I like the parallel tables idea. I also appreciate the table defs for the Audit table. Thanks guys. The Audit table may be a good idea even if I don't make an UNDO feature, and I will be sure not to let that be user updatable. SC Show quote "Arnie Rowland" <ar***@1568.com> wrote in message news:ufBAuKC2GHA.1288@TK2MSFTNGP03.phx.gbl... > It seems that parallel table(s) may be in order. One set for 'work in > progress', and the other for the finished 'committed' state. > > Interim work is placed in the 'Work in Progress' table(s), then to be > committed, it is moved to the production table(s). There could be a > scheduled job that regularly purges the 'work in progress' table(s) of > abandoned rows. > > As Jim indicated, it will get real dicey if you allow 'undos' on > production data -especially when other users are being impacted, decisions > affecting other users are being made on this data that 'may' be undone. > Ouch! > > -- > Arnie Rowland, Ph.D. > Westwood Consulting, Inc > > Most good judgment comes from experience. > Most experience comes from bad judgment. > - Anonymous > > > "catsailor" <hullflyer at gmail.com> wrote in message > news:35df7$45098ad2$48f535c4$32287@msgid.meganewsservers.com... >> Many Thanks Gents, >> I'll do the confirm-commit for the Windows forms. I would love to have >> the web apps store data and commit later, but most are step-wise forms >> apps, kind of like a QuickBooks interview over the web. So, you make >> changes in one form, move on to other web pages and then realize you want >> to go back and restore to the way it was 20 minutes ago and begin again. >> Also, if we automatically commit or don't commit when the browser >> disconnects, either way we'd be in trouble. It's got to be stateless, >> and I can't see how this can be achieved for browser-based apps. I'm >> thinking the Audit table might be the way to go for web apps. Is there >> an example of an Audit table on the web anywhere you know of? >> >> SC >> >> "Gary Gibbs" <ggi***@aahs.org> wrote in message >> news:1158251170.170716.311670@h48g2000cwc.googlegroups.com... >>>I whole-heartedly agree with Jim. However, you could create an "Audit" >>> table. This would be populated by a trigger with all of the old >>> values. You could create an UNDO process where you update the live >>> table with the values for that transaction in the Audit table. >>> >>> Still, Jim is right. It is best to write it into your app and insert >>> the new data only when you are sure. >>> >>> >>> Jim Underwood wrote: >>>> Your best bet is to not execute commands on the database, and instead >>>> cache >>>> the changes in the application. When the user is ready to save, then >>>> issue >>>> the commands to the database. If they want to "UNDO" you simply remove >>>> those particular commands from the application. >>>> >>>> "catsailor" <hullflyer at gmail.com> wrote in message >>>> news:dc09d$45097a07$48f535c4$31889@msgid.meganewsservers.com... >>>> > Greetings, >>>> > I am looking for a way to implement UNDO in my database apps. We >>>> > have >>>> > several SQL 2005 Standard Ed and SQL Everywhere database apps. Some >>>> > are >>>> > connected to web forms and a few others connect to Windows forms. >>>> > What I >>>> > would like to do is give users a command to UNDO some number of their >>>> > most >>>> > recent changes. Like most db apps, a single form submit can change >>>> numerous >>>> > tables in the db in one go. Is there a way to create an UNDO stack? >>>> > How >>>> do >>>> > you elegantly code selective UNDO's? >>>> > >>>> > If you could point me to good learning resources for this, I would be >>>> > grateful. Thanks. >>>> > >>>> > >>> >> >> > > The parallel table idea can get dicey as well. If user one makes a tenative
change to row A and puts that change in in the parallel table and then user two make a change to row A cand commits it into the permanent table, and then some time later user one tries to make his change permanent, you need to be able to detect that this has happened (maybe use a rowversion column) and then decide what to do - force user one to abandon all his changes?, allow the changes anyway?, develop some way for user one to specify which changes to make and which to edit, and which to abandon? There may te other reasons than just that the same row was updated that prevent you from doing the deferred updates. For example, you may have edit checks that check other tables before allowing an update. Obviously, you need to check all of these items when user one made his original tenative changes. Is your business requirement to redo these edit checks when making the changes permanent? If it is and the checks fail, what is your app going to do? UNDO is a neat feature and if you make it work, it can be a great help to your users in certain applications. But if you do it, remember that trying to do this is full of traps and pitfalls. Be very careful with your design to try to design in all the "bullet proofness" you will need from the beginning. Going back to fix things after you have started coding will be difficult. Then QA it with the meanest, nastiest, most devious QA person you have. Tom Show quote "catsailor" <hullflyer at gmail.com> wrote in message news:b771d$450998a4$48f535c4$32553@msgid.meganewsservers.com... > Yeow! People have been asking for UNDO, but I didn't think of the > multi-user problems. Some of these are collaborative apps, so more than > one user could be working on the database at one time. If I lock the unit > a person is working on, it destroys part of the collaborative nature of > the tool. If I don't lock it, someone could undo something and corrupt > the data relationships. I've got to think about this some more. > > I like the parallel tables idea. I also appreciate the table defs for the > Audit table. Thanks guys. The Audit table may be a good idea even if I > don't make an UNDO feature, and I will be sure not to let that be user > updatable. > > SC > "Arnie Rowland" <ar***@1568.com> wrote in message > news:ufBAuKC2GHA.1288@TK2MSFTNGP03.phx.gbl... >> It seems that parallel table(s) may be in order. One set for 'work in >> progress', and the other for the finished 'committed' state. >> >> Interim work is placed in the 'Work in Progress' table(s), then to be >> committed, it is moved to the production table(s). There could be a >> scheduled job that regularly purges the 'work in progress' table(s) of >> abandoned rows. >> >> As Jim indicated, it will get real dicey if you allow 'undos' on >> production data -especially when other users are being impacted, >> decisions affecting other users are being made on this data that 'may' be >> undone. Ouch! >> >> -- >> Arnie Rowland, Ph.D. >> Westwood Consulting, Inc >> >> Most good judgment comes from experience. >> Most experience comes from bad judgment. >> - Anonymous >> >> >> "catsailor" <hullflyer at gmail.com> wrote in message >> news:35df7$45098ad2$48f535c4$32287@msgid.meganewsservers.com... >>> Many Thanks Gents, >>> I'll do the confirm-commit for the Windows forms. I would love to have >>> the web apps store data and commit later, but most are step-wise forms >>> apps, kind of like a QuickBooks interview over the web. So, you make >>> changes in one form, move on to other web pages and then realize you >>> want to go back and restore to the way it was 20 minutes ago and begin >>> again. Also, if we automatically commit or don't commit when the browser >>> disconnects, either way we'd be in trouble. It's got to be stateless, >>> and I can't see how this can be achieved for browser-based apps. I'm >>> thinking the Audit table might be the way to go for web apps. Is there >>> an example of an Audit table on the web anywhere you know of? >>> >>> SC >>> >>> "Gary Gibbs" <ggi***@aahs.org> wrote in message >>> news:1158251170.170716.311670@h48g2000cwc.googlegroups.com... >>>>I whole-heartedly agree with Jim. However, you could create an "Audit" >>>> table. This would be populated by a trigger with all of the old >>>> values. You could create an UNDO process where you update the live >>>> table with the values for that transaction in the Audit table. >>>> >>>> Still, Jim is right. It is best to write it into your app and insert >>>> the new data only when you are sure. >>>> >>>> >>>> Jim Underwood wrote: >>>>> Your best bet is to not execute commands on the database, and instead >>>>> cache >>>>> the changes in the application. When the user is ready to save, then >>>>> issue >>>>> the commands to the database. If they want to "UNDO" you simply >>>>> remove >>>>> those particular commands from the application. >>>>> >>>>> "catsailor" <hullflyer at gmail.com> wrote in message >>>>> news:dc09d$45097a07$48f535c4$31889@msgid.meganewsservers.com... >>>>> > Greetings, >>>>> > I am looking for a way to implement UNDO in my database apps. We >>>>> > have >>>>> > several SQL 2005 Standard Ed and SQL Everywhere database apps. Some >>>>> > are >>>>> > connected to web forms and a few others connect to Windows forms. >>>>> > What I >>>>> > would like to do is give users a command to UNDO some number of >>>>> > their most >>>>> > recent changes. Like most db apps, a single form submit can change >>>>> numerous >>>>> > tables in the db in one go. Is there a way to create an UNDO stack? >>>>> > How >>>>> do >>>>> > you elegantly code selective UNDO's? >>>>> > >>>>> > If you could point me to good learning resources for this, I would >>>>> > be >>>>> > grateful. Thanks. >>>>> > >>>>> > >>>> >>> >>> >> >> > >  |
|||||||||||||||||||||||
Other interesting topics