Access has two big problems, I call them Undo and the Growing MDB. Undo means that when using Access with a form/subform arrangement there is no easy way to "undo" all the changes you've made to the main form record as well as all the subform records. There is no built-in way to accomplish it and transaction processing cannot be used in a form/subform. Microsoft offers an example called "Undofm" that copies all the original records for both forms to a temporary table then allows the user to edit the real record. If the user selects the Undo button on MS's form, the code sends the temporary copies back to the original data source. There is a problem inherent in this system. It assumes nothing will intervene between the time the user copied the source records into the temp table and the time the undo code successfully executes.

     The Growing MDB problem refers to the phenomenon of .mdb files growing larger and larger as users execute code that generates temporary tables in the main program file. The common solution is to compact the .mdb file daily. I've always thought this was an undesirably high-maintenance way to handle the problem.

     I've written a model program that fixes both of these problems. First it has users editing only a copy of the real data and doesn't commit it until they are satisfied with the editing and choose to save the record. So if anything intervenes while they are editing, the original data is unharmed. Second my system keeps all temporary data in temporary databases that are automatically erased when the user exits the program. This solves the Growing MDB problem since nothing is written to the main program database.

     A third advantage to my model is that it places as much of the code as possible into generic procedures and is callable from your form with only modest effort. Importantly all the code that creates the temporary files and moves data back and forth to them is in procedures and could be moved to your own progarm.