• create a summary field type Count of: primary key in the table that your portal points at.
• add a one-row portal with the same filter calculation to your layout
• place the related summary field into the portal
• give the field an object name
• use GetLayoutObjectAttribute ( "objectName" ; "content" ) to get the filtered count (you don't need a field, but can use e.g. a one-segment button bar and its label calculation feature to calculate and display the value)
Note that the one-row portal can be hidden or placed outside the layout proper.
I would do something very similar to erolst except I would define the new field in the portal target table as a Calculation with the definition Get(FoundCount) with the Storage Options... as "Do not store calculation results".
This does not require that the table have a primary key, and it may offer a performance advantage.
I'm with you on that one ...
I would define the new field in the portal target table as a Calculation with the definition Get(FoundCount) with the Storage Options... as "Do not store calculation results".
... it may offer a performance advantage.
... but ...
This does not require that the table have a primary key
... a table that has something worth counting (i.e., all tables with the exception of utility, 'Global' etc. tables) should have a primary key.
Get ( FoundCount )
in the chlld table can be used not only for the portal (filtered or not) in the parent, but also for the report-from-child.
The summary field (in Child) may also be used for the parent-context portal and child-context report.
TRUE: every table should have a primary key
But the calcution field (in parent) to count the child records may not be as useful (should you need the field in the child). One field, many uses.
BTW, the Merge Symbol
may also be used in a portal (filtered or not), if the aim is display. (NOTE: no field created in either case.)
The use of
GetLayoutObjectAttribute ( "objectName" ; "content" )
can still be helpful should the value be needed other than for display (in parent).
Thanks for the advice - I got a bit confused and did it the way that makes sense to me. I just created a couple of extra relationships (Anchor Buoy Method), assigned a couple of text constants and hooked the keys up as with the original portal but linked the text constants in as well. Job done.
I am still very much a novice at FileMaker, but this works well.
Not a clue if it is not as speedy, but the most rows I can envisage seeing in these portals are around 20 to 25 so don't think there will be issues in usability.
Thanks once again for taking the time to try and help.
Hmm, that has messed something further down the line now. Need to retrace my footsteps and will try to do what you originally recommended.