Output individual records as PDF files

I'm replying to your response to Ken. First the relationships window you show is OK except for Contact and Employer. Unless a Contact can have multiple Employers, EmployerID should be a foreign key in the Contacts table. 

The City/Region/Country subform is incorrect. CityID should be on the mainform as a combobox to select a city from the City table. The subform should then be linked on CityID, the city control would then be hidden. The subform does not need to be a continuous form since a Contact would only have one City. So when you select a City from the combo, the subform would reflect the Region and Country associated with that City. 

No VBA is required to create this form.

I've built databases with way more than 100 fields. The key is the proper design of the relationships. I believe I have said before that you need to familiarize yourself with the concepts of Normalization. This is the key concepts on which relational databases are built. For a database to operate efficiently adherence to Normalization rules is essential.  Relational databases tend to be tall and thin, not wide. Its not a matter of Access being able to handle tables with more fields, its that design considerations preclude doing so. Those design considerations are not specific to Access but to relational databases in general.

While I may use some technical terms, like Primary and foreign keys, Joins, relationships etc. They are not that technical and we have explained them several times.

The bottom line here is you really need to lay out your table design properly before you start designing the rest of the app. That's how I do it. It doesn't have to be perfect, but it needs to be logical. You can still add tables and fields as needed. I rarely delete fields. If a field falls into disuse, I merely remove the controls from the forms, queries and reports where it was previously used.

I really don't understand how a relationship that will not allow you to delete a field can exist if its not in the Relationships window. 

And yes, I have worked on many databases created by novices that work fine, but they come to me, when they want to add complexity or automation that goes beyond their knowledge.  Access includes many wizards that walk you through the tasks like embedding a subform or creating a combobox. Which are the two main keys in relating tables.

Hi Ken,

I ran into a snag or replicating your model there. Or perhaps your graphic is in error. Your ContactEmployees table shows both the ContactID and EmployerID as Primary Keys. On my version of Access, I can only set one Field as a primary key.. Again, I don't know VBA to set two Primary Keys in the same table. 

Here is a pic of my Relationships. Notice the relationship between the Contacts and Contact Employers is different than your model. 

Here is the result I get below. Here is the frustrating part. I spend two hours tonight playing with this. I assume I need to learn VBA in order to create your model here. With that, using one table, seems to be a more simpler solution and time effective solution. If I am using only one field to enter the contact info, that should be ok. Right? Again, you speak of data integrity but is it possible to achieve integrity using only one table?