Regarding the diagrams in your post #12 of this thread, let's call them top and bottom diagrams:
The top diagram includes three tables in linear hierarchical relationship but the leftmost relationship still potentially leads to an issue of ambiguity. The left-side "arrow" points from a prime key (PK) to a non-PK field, so that is clearly 1/many. I.e. due to this part of the relationship, you could already get multiple records. The right-side "arrow" points from the Location to the Contacts, but because the left-side arrow wasn't pointing to a unique member, you still have multiple places where an update can go. Then, because the right-side ALSO points to a non-PK field, it could also return multiple records even not counting the left-hand part. Since you "anchored" that relationship in the Vendors table, what that relationship says IN ENGLISH is that you have multiple vendors and that they have multiple agents who are scattered in multiple locations. So there is no uniqueness here and the concept I mentioned earlier (ambiguity of update target) hasn't been addressed.
The bottom diagram is very different. You are pointing the relational arrows to three PKs, so there would indeed be uniqueness in any query that drags those attributes together (vendor, company, contact, location). But what THAT says IN ENGLISH is vendors have only one location, one contact, and one company. Is that what you have?
You are trying to make a query that will, in a single operation, perform updates for multiple tables with (apparently) non-unique common fields. The JOIN clauses in the top diagram would allow that IF you had constraining WHERE clauses to go along with them. The JOIN implications in the bottom diagram disallow creation of multiple locations for a given vendor ID in the first place.
This isn't meant to be a "dig" but at the moment it looks like you are designing by dart board. There is an old rule that applies here and I have to unlimber it. Old Programmer's Rule #1: If you can't do it on paper, you can't do it in Access.
What that means in practical terms is that first you have to get the relationships and their reality CLEARLY understood and delineated. I often tell folks to get a dry-erase board, proper dry-erase markers, and some sticky-note pads. You start with one note for each of Company, Vendor, Location, and Contact (representing tables). Then draw lines representing how you see their relationship to each other. Which ones are unique? Which ones are NOT unique? Are any of those relationships redundant? (Allows you to collapse two tables into one.) For example, if a contact can only represent one company at a time, or one LOCATION at a time, perhaps "Contact" is an attribute of "Company" OR is an attribute of "Location." Perhaps "Vendor" and "Company" are the same thing, one being an attribute of the other. Clarify the relationships and mentally imagine how to start with one piece of info to identify something like, I'm in location X, what vendors or what companies do I call?
Until you can see the unique and non-unique relationships, you aren't ready to put anything into the computer. And you will bang your head against the "one query to update multiple tables" conundrum in frustration. But if you have a diagram in front of you, perhaps you will be able to SEE which relationships don't support your goal. (And I suspect that in some cases, it is possible that what you want can't be done.)
