Some thoughts on the matter. First, Beetle is right about using the BeforeUpdate event to decide whether to allow the update. That works because BeforeUpdate includes the Cancel option and thus you can stop updates.
Second, look into the command-button wizards, which have form options for Save, Undo/Cancel, CreateNew, and Delete based on button-clicks. I have used these extensively.
What I did for the "Save" feature with the "BeforeUpdate" event in place is that on any FormCurrent event, I would set a flag (that I called OKToSave) false. If the BeforeUpdate or FormClose events fired, they would test the OKToSave flag and either cancel or allow the event. (Remember, Close implies a prior save.) Of course, if the form was not dirty, there was no problem because there was nothing to be saved.
If the form WAS dirty and I used the Save button, I set the OKToSave flag TRUE and thus the BeforeUpdate just let things happen. That same event is a good place for audit logging if you needed to do that, because you could know who wrote to a particular record, when they did it, and could even know what machine they were on at least in some cases.
This kind of form-level protection is perfectly possible, but remember that you can have issues if you have either nasty or totally stupid users who take extreme measures to not save something AND not undo or cancel something. They can leave you with some problems if their machine goes down without properly clearing up pending changes.