Are all the portals related to the same underlying table? If so, you may be able to achieve what you want with a conditional calculation.
If not, do they relate to one another, or only the the parent table? In this case you will have to route your calculation(s) through the same set of relationships.
I don't think I can offer any more that that without more detail.
you might need some extra relationships e.g.
you now have
main (tableA) = relportal (tableB)
main (tableA) = relportal (tableB) = same-record-type-records (tableB)
base the relationship on the filter criteria (record type) ( i guess you have fields for that already)
otherwise make a screen shot of your relation graph.
Comparing your two images, I find myself guessing as to which Table Occurrence (box) serves as the basis for your layout and which as the basis for your portals. I'd guess that your layout is based on Subjects 2 and your filtered portals on Results 2 (I'd rename those to use something more descriptive than "2" as this saves future headaches when you forget which are which.)
Filtered portals can be very useful, but the first option that I'd consider is to replace them with portals to three different occurrences of results linked to Subjects by fields that replicate the logic of your portal filter. This sometimes requires defining "constant" fields in Subjects that always store a value needed to match to a "type" field in the portal table. This is how we did it before we had the option to filter portals and in this case, can have two advantages:
- for larger sets of related data, it can be much faster to display
- your calculations can now reference specific sets of records in the result TO's by name as each will have a different TO name to reference.
Yes you have the tables right. I hope you don't mind if ask you to go
back to a more elementary explanation. Are you suggesting I have a
field for each record type in the Results table? I do have separate
fields in Subj table for the calculation results of each record type.
Each subj record can have all three record types associated to it. I
still don't understand how to capture the portal fields into the Subj
record and how to make the relationshipsI tried a GetSummary to
capture summary fields from the result table but it returned nothing.
Currently I am working on script triggers for each portal and a script
that sets the subj fields from the portals. It works on 1 portal . One
does not show a badge and maybe wrong and I can't find the "view" menu
the docs speak of to get to "show triggers" and delete it. Also it is
kludgy as I have to go to each record and activate the portals to get it
to work. Maybe there is a way to automate it.
Your comments and guidance are most welcome.
I am suggesting 1 field with a different value for each type in the results table. One "constant" field in Subjects for each type to use in different relationships that then only link to a single type.
Got it. So the relationships define the dataset, not conditional
calculations. I am new to this but learning slowly.
You really are a FM guru. Many thanks.