Just as docmeizie mentioned, I would also use some sort of an ID field to link the different tables, which then your main form/sub form should follow suit. Take telephone numbers for instance. Now days, one individual could have several phone numbers (Work, Home, Emergency, Cell, Fax, Modem, and Pager, that's 7 right there). Back in the olden days, database system were built with maybe up to 4 telephone numbers, but now, with an individual could have 7 telephone numbers, rather than adding more fields, it would be redesigned to have a separate telephone number table. What this example gets at is data normalization form. It's cheaper to add records than it is to add fields.
With this example, you would have the following structure:
Individual Table:
Ind ID
First Name
Middle Initial
Last Name
Title
Suffix
Type Of Phone Table
Phone Type ID
Description
Phone Table
Ind ID
Phone Type ID
Phone Number
From this point, if you are wanting to look up someone's phone, you can create a SELECT QUERY to lookup information based on either the first name or last name or both, along with the type of phone.
Me, I don't work with bound forms/controls cause with the way the Events are setup, it doesn't allow for the user friendliness of the form for those that are predominantly mouse users and still have the strict data validation checks that I require. Therefore, my knowledge is somewhat limited with regards to how other aspects of bound objects works. I use DAO and VBA coding to do the tasks that I require.
Ronald R. Dodge, Jr.
Production Statistician
Master MOUS 2000
When the going gets tough, the tough gets going.