There is more than one way to link three tables in relationships--even when you use the same value, dateID to link the three. Exactly how the three tables link to each other here is a critical detail. Keep in mind that I only know what you've told me about your database--which is very little so far, but linking a location by date ID instead of location ID seems a bit odd here if the location record is supposed to show the location where the event will take place....
You are correct that unless you use special aggregating functions, a calculation that references data in a related table will only refer to data from the "first" related record. There are a number of different approaches to deal with that, but it's not yet clear which would be the best approach given the limited info about the basic design and intended functions of your database.
Thank you for your reply, Phil. Indeed, there is much missing from my original message!
I have linked by date because that is the common denominator. The layout actually lists a hotel used on our tours. (Location) and is a primary layout for our interface to everything to do with hotels..
We use some hotels a few times in a season, some many times - the portal displays the date(s) of stay and the status of that specific reservation - booked/confirmed, high/low season, etc.
The Event entry is related to the date rather than the hotel - as it happens on the same day that we have an overnight reservation at Hotel XX. It could be a ferry crossing (now that is something to think about while there is one burning off the coast of Greece...) or a walking tour of a city, or the fact that we are taking the entire group to a special event.
I am not interested in having Event detail show up in this layout - simply the fact that any Events taking place on this given day are 'in order' based on specific criteria. (booked/confirmed).
In the screen capture below you can see the layout of the current portal.
The fields Guide Note, Limited Rooms, Off-Site Restaurant all have pop-ups that detail the 1/1 relationship with a relevant note for that day/item. If there is an entry in any of them, and all is OK with that entry the field will be green (similar to those on the left). A problem results in a red box.
What actually sits in the portal row for the Tour excursion is a macro button, running a script to find the related record(s) in the TourExcursion table. Click on the button and, if no records are found, it returns you to the layout noting that there are no excursions/events for this day. If there are, it will open an Excursion layout with the related records in a found set.
I am trying to conditionally format the Tour Excursion macro button to do the same - green, all is ok with all related Excursion/Event records for that day. If there is a problem with any the button should be red.
Is TourExcursion a forth table that you omitted from your original post or another name for an "event" record?
Am I correct that you have a button outside of the layout that needs to be one color if there are no problems in any of the portal rows?
If so, here is a way to test to see that a given value, "x", is not found in the field "status" of any record in the portal:
IsEmpty ( FilterValues ( List ( PortalTable::Status ) ; "x" )
This will return True only if the value "x' is not a member of the list of values returned by the list function. This list function is an example of a special function that can aggregate values from multiple related records.
But your thread title describes this as a Filtered portal. That could be a problem here. If you have defined a portal filter expression in portal setup to limit what records appear in the portal, this calculation won't work as it will reference all related records, not just those that appear in the filtered portal.