If you want one portal to display records from C that are related to the first related record in B, and the other to display the related records via the second related record in B, then I think the easiest way is:
Create two calculation fields in table A
First one = GetValue ( List ( Table B::key ), 1 )
Secodn one = GetValue ( List ( Table B::key ), 2 )
Make two new table occurences of Table C in the Relationship graph
Relate one to the first calculation field, the other to the second calculation field
Use these two table occurences as the basis for the two portals
Could you explain why you would like to split up the C records into two portals as such? This seems very limiting and what happens if there are 3 records in B?
I followed your ideas and had great success with the first portal, related to record 1 of "B". On record 2 of "B" the portal only displays the first related record from "C".
The new table occurrance "c_A1" is mapped to the getvalue1 calc field. Primary key (c_ID) in c_A1 did not work, portal only showed record one too, so I linked the foreign key (b_ID) in c_A1 to "A::getvalue1" and great success. Not sure why, that seems unintuitive to me.
The other TO "c_A2 is mapped to getvalue 2 calc field in an identical fashion as TO c_A1, but only one record shows.
In an answer to MrVodka's valid point which followed your response- the case of three or even four "B" related records can exist and actually will. I figured I could extrapolate the lessons here and deal with that situation after I had a handle on this. Happy to take any suggestions in that respect.
I figured I could extrapolate the lessons here and deal with that situation after I had a handle on this.
Not really. A parent record can have ANY number of child records - but in order to see a specific child's grandchildren in a portal, you need a dedicated field to hold the child's ID.
Perhaps you should present the real problem you are trying to solve, instead of an abstract excercise.
Ditto what comment said...
@comment & mr_vodka: In a perfect world, we wouldn't need to do such workarounds, but the need exists, and the solutions are limited.
@OP: It would seem that in the calculation (getvalue) fields, you need to grab the Key field from Table B that you are using to relate it to Table C.
Thanks for the two comments; I acknowledge the voice of experience here. Conversely, this was not/is not an abstract or futile exercise (for me); rather trying to keep focus on the immediate target, getting the db up and running to cover my here/now conditions. The solution for two children to a parent covers 95% of my immediate needs which is why the question was asked in that respect. Still learning the FM program, so between the manuals and guidance in the forum I have made ton of progress. Thx and best regards.
this was not/is not an abstract or futile exercise (for me)
It is abstract to me, because I don't know what you're trying to accomplish by this. You mentioned a report: I have a vague feeling that what you REALLY need is to produce the report from the grandchild table, with sub-summaries by parent and child.
Just did a recheck on the getvalue calc fields. They both use primary key fields from "B". The calculation fields appear correct when displayed on the layout too. Both fields reflect the same equation, only difference is the end record that is specified, (1 or 2). Tried deleting the 2'nd Table Occurrence and re-creating but no luck. Similarly on the new table occurances a_C1 and a_C2 i'm linking the foreign key (from B) to table A calculation fields. Thoughts why it works for one and not the other?
When excuting a find in "A", all tables one level down show the related records...should that happen two levels down too?
Ok Comment, appreciate the idea. I will give it a try...earlier I tried drawing the report/layout from "B"; unfortunately the found set from "A" gathered two records which I couldn't figure how to limit, basically it repeated all the data.
Only reason I chose "A" initially is it's central- like a hub with multiple child/grandchild relationships as spokes...the central point seemed reasonable to start from.