An "Instructor" table, "Course" table and a "Location" table.
These tables model your main entities, but depending on the real life processes and scenarios, that may not be enough.
A "Grouping" table that will kind of encompass all of the following tables.
Not sure what you need that for – maybe this is a join table (see below), but then you should think of a better name.
Then to also have a Courses layout that will show what Instructors will teach that course and the locations that it is offered in.
Can a course be taught by different instructors in different years/semesters/etc.?
Will courses always be held at the same location?
Consider this model with an additional table:
Instructor --< CourseAtLocation >-- Course
where the central table is a join table that combines courses, locations and instructors (and would have attributes of its own, e.g. year/semester).
From the context of each of the main tables, you would be able to see the related records from the two other tables, by virtue of “looking through” the join table; the join table itself will allow you to search for specific combinations, or create lists and reports.
Just some fodder for thought; your situation may/will be different, but probably not that different.
I do know very little about Table Occurrences. And I know I will likely be needing those but haven't had a lot of luck with them.
Yes, table occurrences and the notion of “context” are the single most concept in FileMaker. Actually, whenever you work with layouts, field objects,scripts and calculations, you're using a TO, never the table itself.
Rather than repeating what others have said much better, I suggest you get a FileMaker book, or the FileMaker Training Series, and become familiar with table occurrences.
btw, the built-in Help system is quite good (if you can manage to find your topic of interest; the lacking index is a sore point …) – so why not start with the introductory sections there while you're waiting for that book to be delivered (or that e-book download to finish …)
Thank you erolst for the quick reply.
Sorry for the confusion on the "Grouping" table, but yes this would be for grouping all of these in a yearly basis. With the setup you mentioned and having the "Grouping" table as the JOIN table, would this allow me to also create the dropdown lists on each layout for the related tables to choose from? So if I was on the Instructors table, and I wanted to link this person to 2 of the many courses on the Courses table, would that work in the portal so it will pull up the rest of the information when I select it from a drop-down list?
To answer one of you questions, an Instructor will be able to teach many different courses at several different locations. And many courses will be taught at many different locations by different Instructors. There are a lot of many to many relationships here.
Getting the Drop-down lists to work and pull the rest of the information from the related table seems to be my downfall. When I try to have it pull, it tends to want to create a record more than pull the information.
Again, thank you for the help and understanding.