I doubt FileMaker created a 2nd file. If this took place on Manage | Database | Relationships. It created a 2nd table occurrence of one of the tables in your solution. That's just a new reference to an existing table and is done to prevent relationships that can be traced in a circle on the graph.
If you are linking employees to Courses, it would seem you need a third table:
Employees::Empl_ID = Enrollment::Empl_ID
Courses::Course_ID = Enrollment::Course_ID
This assumes that one course can be taken by many employees and that an employee can take many courses.
To enroll an employee in a course (including an instructor employee), you creat a record in enrollment with the employee's ID and the Courses ID in order to link the two. A portal to Enrollment on the employees layout can be used to list all courses they have enrolled in. You can add fields from the courses table to the portal row to provide a course name, etc. in the portal rows. A portal to Enrollment on the Courses layout would list all Employees enrolled in the course.
You can set up two portal's on the Course layout that filter the records differently so that one lists Instructors and one Lists Students. Exactly how you filter for instructors vs. employees depends on the version of FileMaker. The simplest version requires FileMaker 11, so let me know what version you are using so that I can describe an approach the will work for your version of FileMaker.
However, couldn't an employee be rated as an instructor in one course and a student in others? If so, then you'll need another table to list their status for each course.
1) Yes, I meant a 2nd Employee Table.
2) Yes, Employees can take many Courses and Courses can have many Employees.
3) Not currently, once an Employee becomes an Instructor, he stays as an Instructor. But I'm sure once I get this working, the powers that be, would like that option of another table so Employees can be an Instructor on one Course and a Student on another Course.
4) My current version is Filemaker Pro Ver 11.0v3 on a Windows Vista system.
I should add that when I set this up I used this configuration:
Employee --< Instructor >--- Course
Employee2 --< Student >--- (Connected to the above Course)
But if there is a better way, please show me the way.
1) No it's a table occurrence. A table is something else. See this thread: Tutorial: What are Table Occurrences?
Yes. There's a better way, see my earlier post. Use a join table (enrollment) to link employees to courses.
Given your current setup where an employee is an instructor or a student, but not both, you can set up two portals to Employee on your courses layout, but use a portal filter on each to restrict the visible records to those that are rated as "instructor" in one portal and those that aren't in the other.
The filter expression for the student's portal would be: Employee::Empl_Code = "S". Change "S" to "I" and you have the filter expression for instructors.
When the time comes to rate employees as instructor on a course by course basis, add yet another "join" table and use it to link your employee instructors to specific courses:
Instructors, like Employee2 in your example, is a 2nd table occurrence of Employees. Now you can list students by using a portal to Enrollment and Instructors by using a portal to Course_Instructors.
1) Right TO not Table.
Once again, thanks for straightening that out. For some reason I seem to be making this harder than it really is. Perhaps because I have been writing web pages using PHP and MySQL and I am used to writing everything out like WHERE statements and so forth.
Well, that's my excuse but I really appreciate all the help, it's working great.