Output individual records as PDF files

Scott, 

While I do appreciate the help, specific examples and instructions don't translate into the type of database I am trying to build. Furthermore, the language you speak in this context may be a second language to you but it is a foreign language to me. My problem is that I don't know the language of database design. In other words, I have as yet found a source that explains, in simple, non technical terms, how Access works. There is always a "gotcha" with the program for novices like me. 

You stated earlier that "Tables don't pull data from other tables. Tables represent an entity that is separate but can be related to other tables." I understand this but relating the table through a form has not worked for me. The database I am trying to create has nearly 100 fields. Can Access handle this many fields because for the life of me I keep running into dead ends. I make two step's forward then 10 steps back. For example, when I try to modify or delete a field, Access tells me that I have to modify the relationship. However, when I open the Relationships tool, there is no relationship to edit. The software is telling me to edit something which is not visible or doesn't exist. It is not logical. It is, from my perspective, a random process full of trial and error. 

I do complex visual effects, depth & displacement mapping of convert 2D images into 3D volumetric motion and other effects. The various software suites I use all allow me to undo and / or make modifications to very complex workflows. From my experience, it is not possible to modify certain items in an Access database.  And that is the problem for me. As a novice, it seems I am required to create a perfect data structure from the get go. If not, Access forces me to delete and start over again. No room for error. With that, is it actually possible for someone without your deep experience to build a database from scratch. 

Again, I only have about 100 fields to complete my database. All the specific examples I have seen have far less fields. I can build a simple database with multiple tables. But I cannot build the database I need. 

What are the limitations? Can Access only handle a a few fields per table?

For each table, I have to enter the client's name to record the data for each client. I was hoping to avoid this repetition.

but without being able to assign a client to each table, I end up with orphaned records. 

but, according to you, I can't pull date from one table to the other unless I create form and subforms.

As it always seems to be with you, you don't listen. You can't make something work, even with specific instructions and examples, so you assume it can't be done.

No you should NOT enter the clients name to assign a record to a client. You should ONLY enter the Client ID (the primary key of the client table) as a foreign key in each associated record. The main principle of a relational database is to reduce repetition.

There is no reason you can't assign a client to each related table. But you seem to think it should happen by magic. I've created hundreds of databases. It is SOP to use a subform to automatically enter the foreign key. Why you can't get it to work I can't fathom. 

Yes you cannot automate the assigning of a foreign key without using forms and subforms. Again, its SOP.

And so I ask again, what is the point of using multiple tables when you can use just one?

In a word, 'integrity'.

A single non-normalized table inevitably includes significant redundancy in that each 'fact' is stated multiple times rather than only once.  This consequently leaves the table wide open to the risk of update anomalies.  Take the following simple model from my DatabaseBasics demo:

As you can see each contact's name is stored only once, as is each city, region, country, and employer name, i.e. at the relevant column position in a row in the relevant table.  Firstly simple errors resulting from inconsistent data entry or typos are ruled out, e.g.  I once found three separate versions of my own name as author of papers in my own field of work (environmental planning), K Sheridan, K W Sheridan, and K V Sheridan.  The first two are correct, but differ; the last is a typo.  As far as the database was concerned I was three separate people.  In a correctly designed database, with an Authors table, my name would only be entered once, so such inconsistencies cannot arise.

By enforcing referential integrity in the relationships between the tables it would only be possible for the region of Île-de-France to be in France for instance, whereas in a non-normalized database it could be shown to be in France in some rows, but incorrectly in Belgium say in others.

As regards data entry all data for the above model can be entered in a contacts form within which is a single employers subform: