Ummmm, sorry, but I feel compelled to throw a monkey wrench into this little project.
Now, admittedly, I haven't completely read every single post in this thread, but I have scanned through them all and I'm a bit unclear as to how we got to the point where your vehicle specifications table is structured as it is (or why it exists in the first place, based on looking at the values you're currently storing in there). Here is the table from your example file;
Looking at the values you have in your VehicleSpecificationsType column, I've been in the automotive industry for more than 25 years and I have
NEVER seen a vehicle where pretty much
EVERY ONE of those values didn't apply. What I'm saying is, unless some of your vehicles are bicycles, these are not optional characteristics. These are hard attributes of a vehicle, and therefore should be fields in the Vehicles table. The way it's structured now, you're forcing yourself (or your users) to first select the attribute (which you will have to do
every time for
every vehicle that you add) and
then enter the value for that attribute. It's not as if some vehicles might not have a VIN, or a Make, or an Engine, etc., so it should not be structured in a way that forces you to actually have to select those attributes for every vehicle.
As far as the actual values for some of these attributes, it wouldn't be a bad idea to have several small "lookup" tables for values that are often repeated. This is common because it speeds up data entry and, more importantly, it ensures better data integrity. This wouldn't apply to something like a VIN, because that is unique to every vehicle, but let's take the example of oil viscosity. Every vehicle is going to have a recommended viscosity, so it's going to need to be entered every time, but if you let users enter it manually you're going to end up with inconsistent values in that column of your table;
5/30
5W30
5W / 30
5-30
5W-30
Then, when you want to query for all vehicles that take 5W/30 you're going to have to query for multiple possible values. On the other hand, if you have a small table to store the viscosities;
tblOilTypes
TypeID (Autonumber PK)
Description (0W/20, 5W/30, 10W/30, etc.)
and use a combo box on your form for the user to select the appropriate viscosity (the combo box would store the PK value [TypeID] in the related table, not the Description), you ensure better data integrity and consistency. This approach would apply some of the other attributes as well (Make, Driveline, etc.), anywhere that you would anticipate having to repeatedly enter the same limited set of values in a field.
While we're on the subject of combo boxes, you should not be using these at the table level. These are commonly referred to as Lookup Fields at the table level and can cause problems. See
here for more on that. Combo boxes in forms are appropriate, combo boxes (lookup fields) in tables are not.