That's real hard to answer, might be a misunderstanding of how I'm reading your question too. Are you new to access/vba? I'm basing my post on that you are, but if I misread the post you can skip to the bottom.

When you say separating the case information into separate tables, you don't mean literally make a table for each case do you?
When you say pull up a subform do you mean open a new form? Not a subform inside of the main menu form?

I'll be honest, you have kind of a wide spectrum of stuff here, I'm assuming you might be skipping some steps trying to run before you can walk kind of thing here. Unfortunately, with most things programming (VBA too), you can't just learn how to do one thing and copy/paste it, you'll have no clue what to do later when you have to troubleshoot or need to add more to it. The only real way is to start with a strong foundation knowledge that you get from starting at the beginning and going through the classes one by one, there is not really specific lessons that are going to teach everything involved (there's many tiny things that you don't even know that you may need yet, like DLOOKUP probably among others), it's kind of just an understanding of everything.

Some of this is covered in these videos, but again in the scenario that you listed with changing multiple list boxes or outside forms, you're going to need more advanced VBA to do it, and there's no real shortcut there other than starting at the ground up.
Relationships
Many-to-Many
Search Form 2.0

100% With Adam. Access has a steeper learning curve than Excel due to its ability to do virtually anything. Assuming you are new to Access, recommend going through Access Beginner 1 To Access Expert 2. That'll give you an idea as to the scope of what you'll need to learn. That said, once learned, sky is the limit.

Im not making a separate table for each case. Basically, I had too many fields to put in one table, so I grouped some fields into sections, and I created those sections as separate extended tables. I then created individual forms for the extended tables for the user to input the information. Visualize a binder with plastic tab dividers, in which the entire binder itself is a case and therefore one record. The tab dividers are the extended tables. Now picture these binders are on a shelf, each with their own case number. Which lessons will help me understand how to link the tables, so that the user can search for a case number and pull up one record and all of the information for each field associated with that case across tables. Should I make a union query? and then use this query to create the search object?

Anytime someone tells me that they have too many fields for a table that screams to me improper table design and lack of understanding of relationships.

Technically you can have 255 fields in a table.  Realistically I don't think I've ever gone over 50. (I haven't counted though)

In addition to the Relationships and Many-to-Many videos Adam linked above watch the
Normalizing Data
Too Many Tables videos for a bit more on table design theory.

If you are really serious about designing a good database, the advice above about starting at the beginning and working up is really good advice.  In Access you really do need to learn to crawl before you can walk ( then run).

Hi Cal, you don't need to create separate tables just because there are too many fields for a form to fit on a screen.  There are ways to get around those issues, such as using a vertical scroll bar for a very long form.  Your multiple subforms can point to the SAME table; you don't need separate tables for that.  Please see the free video Too Many Tables on this site and on the YouTube channel.  Sometimes, even two tables are too many.  You need a good reason to split up tables, and this doesn't seem like a good one.

The major downside of having even more than one table is that multiple tables need different NAMES, and that complicates everything from designing queries to writing VBA code.  Every big blob of related information, no matter how big, should belong in ONE table, provided you have under 256 fields as Scott said.  If a movie table needs 100 fields (title, year, country, genre, IMDb ID, Letterboxd ID, Wiki page link, etc. etc.), then they all should be in one big "Movies" table.

Your users don't look at your tables; they look at your forms.  This problem can be and should be solved strictly with form design.