Here is the low-down and at a very low level.
Access wants to save data on forms that are bound to tables or queries. That is one of the purposes of forms. Any action that would move the focus of operation to a different form (including a sub-form of the main form) will trigger Access to save what it has. Closing a form that has some data also triggers a save operation. It is designed that way because it doesn't want to lose data.
When you have a form with some but not all of the required data, you have a couple of options. The most common one we recommend has to do with event programming. You have admitted you are very new to Access. So... an event - to Access - is a situation that is relevant to the things Access does. Like the Form_Open event, which "fires" when you open a form. Or the Form_Load event, when the form starts loading data. Or the Form_Current event, when a form bound to a record loads all of the data from that record into the controls on the form. That is to say, the form and record currently match.
In each of these events, Access allows you to drop a bit of code in VBA "behind" the event. In form design mode, open the form properties display, which has four tabs, and open the EVENTS tab. The idea is that Access performs all of the events you see. Whether or not you drop in some code, those events WILL happen. BUT if you follow the procedures to do so, you can add a bit of your own code such that when that particular event "fires" then Access will call your event subroutine that is specific to that event and that form.
The event you want is the Form_BeforeUpdate event. I mentioned that Access will save data automatically. It will also do so if you have a command button to implement the acSaveRecord operation. Any of the automatic or manual cases, what is ABOUT to happen is that Access will write back the data on the form to make the corresponding record match the form. However, that particular event has the option that you can cancel it. Here is a link to the event and it has some code samples.
Office VBA reference topic
docs.microsoft.com
The idea is that if you write a Form_BeforeUpdate event, you will have a chance to examine the controls on your form to see if there is something wrong. If not, you just let things happen. But if there is an error, you can cancel the event, which will cancel the update. The form will not do whatever it was about to do. For example, you can't close a form that needs saving if your code cancels the update. You can't navigate away from the current record if your code cancels the update.
There are other problems here as well. If you try to close the form and it is "dirty" (data needs saving), the question is how you would know that the attempt was being made to close the form rather than navigate it or simply leave the form for a sub-form or another form. This becomes extremely complex. I can't advise you farther than this because you have to decide what way you want to handle the problems in a procedural sense. That is I can't give you code samples because at the user level, you have to decide what should be done. Do you want to Undo all changes? Do you want to block closure? Do you have some other action you want to take, not at a code level but at an operations level? That is why I can't tell you what to do.
