[AccessD] Many to Many relationship issue

Correct. The fkjobid in the calls table will tell you the job, and the
fkcompanyid in the Jobs table will tell you the company.

A moment on language.

I don't like to confuse contact, with attendees.

A contact can change, an attendee cannot.

A company contact table might help you determine who is current at the
company - and this data is worth keeping up to date for its own sake.

A call detail supplementary table is properly called a CallAttendee (or
CallDetails) table. This avoids confusion, as for all you know, the company
might ask a contractor to sit in on the call for them, or you might be
dealing with their agents and not principals of the company.

So while contacts might suggest attendees, they are not the same class of
data.

Now that that is clear, note that you have to decide if there will be a
single representative for a company on a call... or potentially more than
one.

If just one, you can store name and role values in the calls table. If more
than one, you need a callattendees table, in a normalized database, with
fkcallid pointing to the calls table.

You would put name and other details in the call attendee table, and the
details in there, instead of the calls table.

It will sink in. It takes some strategy for sure.

Ready for really messy? How about conference calls with from 1 to N
contacts at fro 1 to M companies discussing from 1 to P jobs that any or
all of them might be interested in.

It can be done but I am not going to try it now unless forced to. And as
hinted at earlier we have not even hinted at project roles.

I am going to suggest 2 things. 1 is that you have a contact table for each
company that is CURRENT information. And that you have, instead of a
callcontact table, if you need one (ie, more than one company contact per
call) a CallAttendees table. Because the people in that table (or in the
calls table if just one present at a call) are not necessarily current
"facts" about the company, and any time I use the word "contact" in a
database that is something I want maintained as current and up to date.and
I might use a combination of previous call attendees and current company
contacts to help me choose names who were available for documenting
attendees on the current call record (a pick list which helps avoid
proliferation of name spellings), while still offering a "New Name" if
needed. Next time this new person will be in the pick list.

.....

For fun, Try getting your mind around this one and you will understand why
the more you can store in the cal

At Time 1 (call1), Person P1 was in project role R1 at company C1 on Job
J1, a government job. At time 2 (call2), company C1 and C2 were
consolidated into company C2, Role R1 was consolidated along with R2 and
R3, into role R4 for government jobs, R5 for non-government; person P1 was
promoted within C2, replaced by person P2 on Mon-We, and person P3 on
Thu-Fr, since they job-share (hint: we don't care, we are tracking
attendees and their roles at the call level, not company level, we never
change history, and the most we might be concerned with is adding Role to
the callcontact table and updating historical Rd values to R4).