You have two options and can choose either. It wasn't intended that you would handle both options, but rather that you could pick the way you wanted to handle it. But I can't answer your question because this is your project. You have the choice of blocking the closure of the form or of just discarding incomplete records. But until you decide how you want to treat this in practical terms, the code will make no difference.
From this question, I think it is time for me to unload some "Old Programmer" proverbs.
1. If you can't do it on paper, you can't do it in Access.
In any project, you have to have goals. Usually, people lay out their goals in a design document or specification. You are building a program to track the actions of your business. In order to do that, you must intimately understand your business flow. You must know the data elements (entities) of your business, whether we are talking employees, clients, sellers, buildings, equipment, sales, purchases... WHATEVER is part of your business. You must know the intimate details of how those things are used. Many of your tables will represent those things. Whatever is done in your business, you must know how it flows.
How you lay out your goals is up to you. But the general approach is to identify the entities you will track whether concrete or abstract. You identify how these entities interact. You lay out your desired outputs. In essence, you must build a roadmap of how you get from inputs to outputs by all of the processes in between. You answer the questions of "how will I do that step?" by looking at the step in the real world and deciding how to perform that step (or record it) in the computer. When you are done, you have a document that should answer all of your "what happens to this entity at this phase of my business?" At that point you have a roadmap. And if you are going somewhere without a map, how in the world will you ever know you have arrived?
2. Access won't tell you anything you didn't tell it first, or at least tell it how to find it for you.
Let's start by understanding that Access is dumber than a box of rocks with regard to the real world. All it knows is data manipulation and making pretty forms and reports. YOU are the subject matter expert. Access cannot learn anything - but you CAN write code to show it how to do some step or another. You have outputs. Access can only tell you those outputs if you make the required inputs available. Sometimes, it becomes necessary to look at an output and work backwards through that map to verify that you will have the inputs you need to produce that output. That is, if you want X, Y, and Z as outputs, you need inputs for X, Y, and Z. AND if you want XYZ as output, you need X, Y, and Z and you ALSO need the formula that mixes them together. Consider this a type of "procedure checking" perhaps. Just remember, you are the one who must make stuff available for Access. It is an ORGANIZING and COMPUTING tool. Not a manufacturing tool.
3. Access can never tell you how to do your business. Only YOU know how to do your business.
People want Access to help them run their business. Yes, it will do that... if you tell it how you run your business. Access will not make a decision for you that you wouldn't have made. This is an important concept.
In English, we have a phrase that we use: The tail is wagging the dog. The Access equivalent would be if your application told you how to run your business in a way that was contrary to the intent of the business, but you let an inanimate object guide your business. If you build an application for your business but it is an imperfect representation, you could find yourself in real trouble if you followed it down your garden path. Remember, except for true AI cases, computers don't come up with new things. Their strength isn't based on creativity, but rather that they can do things QUICKLY and ACCURATELY. But give them a bad formula and they can still be wrong.
When I worked with the U.S. Navy, the biggest project (for which I was a systems administrator for the host system) was a personnel management system. They modeled the heck out of personnel transactions such as addition, separation, transfer, promotion, demotion, training, etc. We gave the bosses at BUPERS all the details they needed to make decisions. We had models for every decision they could possibly make. But THEY made the decisions based on what our DECISION SUPPORT system showed them. They ran the show. We just tracked their choices and helped them push the appropriate orders to the appropriate channels. Our machine never told them what to do, though it sometimes told them what they couldn't do (if, for example, no one was eligible for a particular assignment with requirements). The point is, whatever you design has to support how your business is supposed to run. Back to the map analogy... just remember that the app your are building is the map; the actual business is the territory. Be sure they match up.
and you are Phd Chemist very niceeeee. 
