in a calculation, any reference to data in a related table can only access data from the "first" related record. Any other related records might as well not exist as far as the calculation is concerned.
There are ways to deal with this:
Use ExecuteSQL to get the desired data.
Build the logic into the relationship so that an unfiltered portal shows the desired records. Of course, this isn't always possible.
Don't use a portal. Use the "logic" of your expression in a find that only finds records that meet the needed criteria. Sometimes multiple finds or a loop that omits records has to be part of that process.
These are just very general descriptions of options. It would help to describe your report and why the filtered portal itself can't be used as part of that report.
Thank you for your suggestions. I’ll look for some ExecuteSQL examples; all new to me but definitely worth learning. Not sure what building the logic into the relationship would look like. And your third suggestion, assigning the value with a script is probably something I can manage.
The reporting is simple. We just need to summarize the number of clients that fall into each category. I can display the filtered portal on a report of Programs, but I can’t figure out how to count incidences in each category. Switching it around, I could probably count Programs from the perspective of the category, if I make those categories into a related table. Is that on the right track?
To count related records in a filtered portal, you can add a "count of" summary field to the portal's table (set it to count a field that is never empty) and then make a one row copy of your filtered portal and put your summary field in that row. The "Found Count" layout object could also be placed inside that one row portal to show the number of records. Other aggregate values such as a total, average, Maximum, etc can also be done in the same manner.
But what you describe also sounds like something that might be managed with a summary report where you use sub summary layout parts and sorting to group your records. The same "count of" summary field, if placed in such a sub summary part could also provide your counts for each category. Such a report can be set up to list every record in each group that is counted in that fashion, or you can just show a row and a count for each group.