Access gives you the Cancel argument so you can cancel the event, i.e. stop
the record being saved. Just set Cancel to True to kill the save.
You can optionally undo the form as well, which is saver than:
DoCmd.RunCommand acCmdUndo
because:
a) it works even if the form does not have focus, and
b) it undoes all changes, not just the one field.
So:
Cancel = True
Me.Undo
You do not need:
DoCmd.Save
That does not save the record anyway (it saves form designs). More
importantly, Form_BeforeUpdate only fires when Access is trying to save the
record, so unless there is a problem or you cancel the event, the save will
happen.
If the user clicks the close button at the right of the form's title bar
when the record cannot be saved, Access (appropriately) gives the user the
choice to go back and fix up the bad entry or lose it. That makes sense.
However, if the form is closed using the Close action in a macro or the
Close method in code, Access *loses* the entry, *without* notifying the user
that the entry failed! From the user's point of view, they have no idea the
data was not saved, or why, and later they may come to believe that Access
is an unreliable program that cannot be trusted to save the data.
To avoid that problem, always explicitly save before using the Close action
on a bound form. In a macro, use the RunCommand with SaveRecord. In code:
If Me.Dirty Then Me.Dirty = False
DoCmd.Close acForm, Me.Name

Signature
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
>I have a field that can not be set as required at the table level so I have
> code at the form level to decide if the field is required, and then force
[quoted text clipped - 35 lines]
>
> End Sub