the default action, as per request is not to save.
As the others have said. The standard behavior of Access is to save. In fact, Access takes saving records as a personal mission and it saves under numerous situations. In fact, the usual complaint is how do I stop it from saving rather than how do I make Access save. But the question is only asked by people who don't understand the form's BeforeUpdate event. Plus as I showed with the picture, the change appears to have been saved since the pencil disappeared.
The code you have posted is dangerous and others should know. Rather than complaining and accusing me of attacking you personally, just say "thank you, I didn't notice that. I'll fix it".
@KitaYama FYI, Access wraps your Form inside a transaction already so this code is wrapping the transaction inside a transaction. Sure, it's cool. It's a class module which no one understands. But to what end? It appears from his response, arnelgp's "end" is to stop Access from automatically saving. However, Access gives you complete control over whether or not the form's record gets saved. All you have to do is to understand the form level events. Those are what Access uses to control the transaction it has already started. To cancel a save, just use the Form's BeforeUpdate event. You don't need a class module to do this. You are already in one.
There are valid reasons for using transactions. A single record update form isn't one of them. Transactions are used when you need to make multiple updates and you need all of them to be committed or all to be rolled back. The most frequent example is double entry book keeping. You need to add both the credit and the debit entries inside a transaction because if one is committed and the other isn't, the books will be out of balance. It is also used for certain batch updates. For example, in a credit card processing center, a check is received and it needs to be split to apply to multiple accounts. Again, all the separate transactions need to be applied or they need to be rolled back. I used to use transactions quite frequently back in the olden days when I was working with COBOL and doing lots of batch processing. We would need to process an entire file of input records. Since the files were so large, we would take checkpoints within the transaction so that if something happened, we didn't need to go back to the beginning of the file, we could resume at the last valid checkpoint. Not much batch processing gets done with Access but I've actually done some. One of my clients offered home healthcare services to private pay clients as well as those on Medicaid and other government programs. Most services were paid for by the state and so each month we would have to send (invoices) and receive (payment confirmations) files that could go to a million records since each visit for each client generated a transaction and the transactions which were EDI (Electronic Data Interchange) could be multiple records each. Transactions came to the rescue. checkpoint after every 20,000 transactions (which could be 100,000 records) so if something happened we wouldn't have to reprocess the entire file.
