On Thu, 1 Apr 2010 13:11:01 -0700, Kathryn
wrote:

At the moment, the tables are pretty separate - the only Contact/Event links
are the organiser and, where needed, a Billing Contact - the other Contacts
are our mailing list... This may give a clue as to what another table needs
to be? My aom was to have one form for everything for myself and receptionist
and then various forms for details that others can access... this may be too
ambitious?!

Here, anyway, are the Form's RecordSource properties...

SELECT Events.*, Contacts.Title AS Title_Contacts, Contacts.[First Name] AS
[First Name_Contacts], Contacts.[Last Name] AS [Last Name_Contacts],
Contacts.Address1, Contacts.[Town/City], Contacts.County, Contacts.[Postal
Code], Contacts.Billingaddress1, Contacts.[BillingTown/City],
Contacts.BillingCounty, Contacts.Billingpostcode, Contacts.Billingtitle,
Contacts.BillingFirstName, Contacts.BillingLastName, Contacts.[Business
Phone], Contacts.[E-mail Address], Contacts.[Mobile Phone] FROM Contacts
INNER JOIN Events ON Contacts.[ContactID]=Events.[Contact ID];

The Contact table's primary key is ContactID, the Events simply ID. The
relationship is Contact: ContactID Events: Contact ID.

If each Contact is related to zero, one or many Events, and each Event
pertains to one and only one Contact, then I'd suggest using a Form based on
Contacts and a Subform based on Events. This will be a lot easier to manage
than munging the data from the two tables together in one query and splashing
them all up on a form.
--

John W. Vinson [MVP]