Is it possible to implement an "undo" command?

[Young Padawan]

I want to be able to reverse the last change a user has made. Maybe the solution is incredibly easy and I'm just not seeing it

[Ender]

The "easy way" is to not commit the record until the data entry is done, then show the "Do you want to save changes?" dialog. Once the record is commited, it's a whole lot more work to undo things.

Undoing changes that have already been committed will require audit logging on any fields that might need undoing. This is pretty complex to implement fully. I think there's a sample of how basic audit logging works on databasepros.com. To be able to undo the changes requires looking at the audit log (for a particular session and table or record) and going back to the previous state (which would need to be recorded in the log.)

[transpower]

Add a Revert button to your layout, with the script step: Revert Record/Request.

[Ender]

Add a Revert button to your layout, with the script step: Revert Record/Request.

Revert Record/Request will only undo uncommited changes. Once the record is commited (automatically or via the Save dialog,) Revert won't help.

[Computer Geek]

Young,

Depending on what you want to have the ability to undo, it might be worth your time to set up an audit log system like Ender mentioned. Depending on your solution, you can set up a duplicate table and with a script, duplicate the record. If there is a need for an undo, another script can reset the main table with the values from the duplicate table.

The problem with the commit / revert record process is that there are numberous ways that the user can implicitedly commit the record. I prefer to do it my self and know that the undo will really undo.

[mattlight]

It's all dependent on this committed state. Well, when you click on yes to the question "Do you want to save these changes" I think it's fair to say that no-one would really expect to be able to reverse that process - especially if more than one field.

The only real easy way of doing it using an extra field is to have a HISTORY field which records most of the stuff you type into the Current database. When you click on MODIFY, it runs a script that basically puts in the date, time, username and a quick copy of all the existing field contents into.

set field(history, History = History & Field 1 & {RET} & Field 2 & {RET} &...)

then go to layout data entry and change the contents of the fields.

As far are avoiding the regret of changing some details BEFORE committing, You could use a set of 10 new INPUT fields as data entry fields on a layout that allow you to enter in the data before committing them to the fields. Then click on SAVE or CANCEL for it to either do script routine to copy into the actual fields of forget it.

At least long after you have changed the contents of a record, you can see what it was originally in the HISTORY box - also, with every script execution, get it to write into the HISTORY field what you've done

set field(history, history & "Printed" & Current(Date) & " " & Current(Time))

The only thing you shouldn't do is have the ability to DELETE a record - if you do, no audit trail available to you - just flag it as voided and omit that record from reports.

[Munchie]

Hello YP,

If it is only necessary to be able to undo a few fields at a time, you could create a script that will do this.

For example, I have a script that will undo changes I made to a credit card. I do this by having the data entry done with dialogs. After the data is entered into the dialog, the script copies the old data to a global field, and replaces the target fields with the new data.

If a user wishes to undo it, there is an undo button that will pull the data back for them.

I only use this on specific sensitive fields, however I don't think it will work for you if you want a system wide, always available Undo technique.

Hope I've been of some help.

[Oldfogey]

The short answer to the original question is 'Yes .. but ....'.

I have implemented three different undos. (Should that be 'undoes'?) One undoes deletion of unwanted records (part of a cleanup/archive), one undoes a few (restricted) field changes and one is too complex to describe here. The technique in each case is quite different. The first involves a holding file, the second a pushdown list and I can't remember the other.

'Undo' really has to be designed for the particular circumstances. It always entails saving the original data OR saving the new data. On the surface, V7 gives you a sort of undo but not really; it gives you a 'final do'.