I have three related tables. For simplicity sake let's just call them table A, B, and C (I'll be referring to the table occurrences and corresponding portals by the same names).
You may think using generic names makes it easier thinking this problem through, but it ain't so. Please call your tables by their proper names.
That being said:
Selection 1 - select a record from T.O. A
That “selection” is actually being the current record, since the layout's context is table A?!
- I created a second T.O. of Table C with a foreign key field which stores the the value of the primary key field of the record selected in portal B and related it to the global field found in T.O. A
I don't really understand that sentence. To achieve your goal, you need a relationship
A::globalPrimaryB = C_aNewPurposeBuiltTO::foreignKeyB
where, according to
- T.O. A has a one-to-many relationship with T.O. B, and T.O. B has a one-to-many relationship with T.O. C.
foreignKeyB must an attribute of table C anyway, and every record already has a value (of some B record); so there's nothing for you to do in the “back-end”; you only care about the front-end.
Which means that
- I created a second T.O. of Table C with a foreign key field which stores the the value of the primary key field of the record selected in portal B and [,] related it to the global field found in T.O. A
you can forget about the strike-through part.
To debug this, I suggest you put globalPrimaryB on the layout, put in a known value and see if records appear in the C portal. If they do, you know that the relationship works; if not, adjust. Then take care of your trigger/script.
Good morning erolst,
I hope your day is going well. Thank you for responding to my poorly described problem. After reading your response I think the concept of context finally clicked. The only thing I needed to change was the relationship assignment of T.O. C (I will be taking your advice on using real object name for all future posts) and the corresponding layout and portal associations. As I mentioned in my initial post, originally T.O. C was related T.O. B when it should have been related to T.O. A.
Although trying to describe the complete configuration would cause more confusion than understanding, I do think it may be useful for other new comers to FileMaker Pro to hear my revelation regarding context - I apologize to those of you who may find this obvious. My original intent was to include two portals - displaying information from different TOs - on one layout, which would allow the end user selection of a record in the first portal to filter the found set of the second. I spent nearly two days beating my head against a wall because I failed to grasp the concept of context in my design.
What I realized was that FileMaker provides you all information, from TOs displayed via portal, that is related to the current record selected on you layout, regardless of how many relational steps away from the primary TO you are looking. In my case, I was viewing records through a portal that were contained in a TO which was two relational steps away and was trying to filter the records of that portal using the relationship to the TO that was one step away; I was completely unsuccessful. Perhaps an analogy would be helpful at this point...
Imagine a train that consists of a locomotive, one boxcar, and a caboose. There is one person in the locomotive, one in the boxcar, and one in the caboose. From the perspective (context) of the locomotive you must look through the boxcar in order to see into the caboose. In my case, I was trying to see the contents of the caboose without seeing the contents of the boxcar as well; not possible. So to resolve the issue, I changed the relationship diagram to look more like multiple water-skiers tied to a single boat rather than a train and used global fields to filter the found set displayed via portal where necessary.
I realize the analogy I chose is not perfect, and it's easier to understand a concept than it is to teach it, but my point is this: Understanding context is extremely important if you want to take full advantage of the power of the relationship graph.
Thanks again for your response! Have a great day!