The portal works fine.
The concept you are missing is that there are no related records to display in the portal.
This is because the field you have named "Foreign" in the "Foreign" table is empty.
As a matter of fact, the field does not even show on your "Foreign" layout.
You need to work on how the "foreign" key gets populated.
This will be easier to work on if you come up with realistic examples of where you intend to use a portal.
Then you would know what the key fields would be.
Portal Trial.fmp12 2.zip 11.9 K
Can you be more specific on what needs to change about the foreign key. I have populated it with entries in the past and nothing changes (just tried with the portal trial and my actual database...nothing is different). If its indexed to equal another field shouldn't primary=foreign or do I misunderstand that. Should it be a calculation that sets it equal to the primary.
1 of 1 people found this helpful
frankcro, let's try to make it a little easier to understand;
mainID_pk (this is the primary key - unique - that is an auto-enter value)
childID_pk (this is a primary key for the child records)
mainID_fk (this is a foreign key and is the MATCH to MAIN::mainID_pk in the relationship graph
MAIN::mainID_pk = CHILD::mainID_fk
make sure to allow creation of records in the CHILD side of the relationship in the graph
The context of the layout ifsthe MAIN table. The portal to CHILD table is based on the relationship in the graph. All fields in the layout are from the MAIN context, __EXCEPT__ the fields in the portal (and there may be other fields such as globals that don't require a relationship). The fields in the portal must be from the CHILD table (or related fields from another relationship to the CHILD table).
As you enter data into the other fields in the portal row(s), the mainID_fk is automatically populated with the correct information.
You may also script the creation of related records, by passing the primary key (MAIN::mainID_pk) in MAIN and upon creation of the CHILD records, set the foreign key (CHILD::mainID_fk). Either way these records will show in the portal.
The reason the fields in the portal may appear empty is:
1. the foreign key is not set (by script or data entry in portal where the allow creation is set on the relationship)
2. the wrong fields are in the portal (wrong context for the portal)
If you think of the portal as what it is named "PORTAL" (a view) into another table by relationship, you will keep your context correct.
Did you download and examine the revised example?
Nothing needs to change about the DESIGN.
It works correctly now.
You had two records in the Primary table in your example. They had a value of 1; and 2; in the PRIMARY field.
You had two records in the FOREIGN table. The field "Foreign" in both records was empty.
When the field is populated with a value that matches one of the values in the Primary table, the record will show up in the portal.
In the case of the returned example, I merely put 2 in the Foreign field of both records in the "Foreign" table.
Again: you should provide a meaningful real world example to talk about.
Regarding this statement:
"I have populated it with entries in the past and nothing changes (just tried with the portal trial and my actual database...nothing is different)"
Sorry, that is impossible.
The Portal trial database, as you supplied it, did not display the "Foreign" field anywhere.
Therefore it was impossible for you to populate those fields.
Once they were placed on the layout for the "Foreign" table, THEN you could populate them; and THEN the portal displayed the correct records.