Preserving the state of the database


I would like to preserve the state of my database, including the current selection, grouping, totals, sorting and saved state while I do some other activities, which alter the state, and without knowing how I got to the original state. (Window position is not an issue and other activities will not alter any windows.) Then when I am done with my other activities I can return to the original state. Is there a way to take a snapshot and return to that condition?


Why not just choose Duplicate from the File menu and do your other activities on the copy that opens up. When you are done with that work in the copy database just close it without saving and you will return to your unchanged original file.


I was thinking about creating a custom statement that would tally the number of occurrences of values in a particular field. Maybe you saw the earlier question from Michael K about using an array filter. Another approach was to group up, then total, then build an array from the rows with the total. But that approach would alter the state of the database. I want an approach that leaves the database unchanged. So doing as you suggest would accomplish the task as I explained it, but not meet my larger purpose of creating a statement of general applicability that would leave things unchanged and require very little input from the user (just the field name). I, with Michael’s contribution, have done this with a loop, but was tinkering with a more elegant solution.


If you do NOT want to make (and keep) any data changes, you can simply use the menu command File > Revert To > Last Saved Version.
When you accidentally did save during your modifications, you can use the second option File > Revert To > Browse All Versions and pick a previous version.


Tom, have you tried using the startdatabasechange method before the rest of your procedure code runs and then ending it with `sendaction “undo:”? Unless you you are doing something in the code that is not supported by the undo you should be able to accomplish the task. I have used this successfully on a number of occasions with some rather robust code being executed in between. Here is the general scheme:

startdatabasechange "allrecords","Undo Procedure"
// do all your stuff here
sendaction "undo:"


I think that works. I had not thought of that, but I don’t know enough to include a ‘sendaction “undo:”’ statement.


Kurt’s suggestion of revert is simpler and it works with your code Tom, with the limitation that it doesn’t return to the field that was active at the last save - neither does the undo approach. That’s because your code creates a new field and then deletes it. If it’s important to return to the same active field then I’d go with Gary’s initial suggestion of working on a copy of the file.


In my testing, the procedure leaves the active record and the active field unchanged. Tom