This thread is completely off the rails.
@MatthewB
I created a query using the SQL you posted back in #12. It ran fine for me so I was correct. The Querydef was corrupted. I don't know where that leaves you since the thread has gone sideways.
However, you have several severe design issues with the tables.
1. Some relationships are pathological. For example, you have StrataPlan_ID as a FK in Quoting but you have Quoting_ID in StrataPlan. You CANNOT have a 1-m relationship and have the m-side key in the 1-side table. Not possible.
2. You also have a number of repeating groups. Look at every column that has a numeric suffix. Those fields belong in a separate table. It doesn't matter if there's only four of them. You've made a hard limit where none should exist, plus, you've complicated all processing.
3. You are not using the Autonumber PK in the FK relationships. You are using some other field. The ONLY reason to ever have an autonumber in a table is because you are going to use it as the primary key. NEVER, include an autonumber in a table if you are going to use some other field as the PK. I know it "feels" easier to you to use StrataPlanNr as the FK and it is not actually wrong. I would not use any field that I do not control as the PK. I've been burned too many times by this. Someone changes the format of StrataPlanNr and you have to change the value of your PK. If you don't have RI enforced and you don't have Cascade Update specified, this is a nightmare. Besides, no PK should ever be allowed to change, hence the reliance on surrogate keys like the autonumber. StrataPlanNr becomes data. You can still use a unique index to ensure the business rule of uniqueness is followed. You can still search on it. You can still show it on every form where it is relevant. Users never have to see an autonumber. The only person who is inconvenienced is the developer who sometimes wants to just look at raw data in tables while testing and it is always annoying when that data is a meaningless autonumber rather than a meaningful StrataPlanNr. So, the answer is to use queries so you can join to the StrataPlan table. If you are going to use some other field as the PK, get rid of the autonumbers before they cause a problem. There is a lurking bug which may or may not be fixed that causes the autonumber seed to go wonky in tables where the autonumber is not being used as the PK.