I'm not ENTIRELY clear on your intent, but I'm going to take a shot at it anyway.
You need to prevent navigation and premature closure of the form because those things will cause a "hidden" update. This prevention can be managed by event programming.
You put a "BEFORE UPDATE" event on the form that will fire before the form would do something to perform an update. If what you wanted to be has not been done yet, this particular event call includes a Cancel argument. If you return a value of -1 (or TRUE) to that argument, then Access will not allow the update to fire. If that event is the result of either navigation or a premature CLOSE action, it won't close so easily.
This implies that there will be code in the command button (? GO_SET, you called it? ) to set a flag that says, "Button was pushed." The button-click event for this button would do whatever you had it doing anyway - but you add one line to set the flag. Then the event code would check the flag before deciding whether to cancel the event or not.
To go along with this, you need to clear that flag in the form's "CURRENT" event because that is a moment when there is nothing to save on the form because the form and underlying record match.
And finally, where would this go? Since everything in question is form-related, you put the flag variable in the form's common declaration area that is at the front of the form's class module. Things declared in that area are still private to outside code but they are public within the confines of the form itself. So each routine can see the flag - the Current event, the Before_Update event, and the button OnClick event.
Your message box would go in the Before_Update event IF you decide to cancel the update. Before you return from the event, you return -1 to Cancel and you pop up your desired message box.