Base the report on Dates, not Classes. Reflect any fields you need from Classes as related fields.
Thank you. I will try this but I’m confused because I can display the data I want in a portal placed on a layout based on Classes but can’t seem to do this with a sub-summary report based on Classes referencing fields in Dates table using the same TO.
I’m obviously missing something basic or I didn’t explain it properly in my original post.
For each Class, I want to show a list of the dates based on Start and Stop dates in Classes and based on which days of the week the Class is being held. Days of the week are selected in Classes using a checkbox field.
I’m not understanding why this report should be based on Dates when it works fine from Classes via a portal to Dates.
I’m not disagreeing with you. Just wanting to understand.
Portals point from the parent table to the child table. They show a one-to-many relationship. The context is the parent table, which means each record is a parent (in this case, a class). They filter and display records; they manage the relationship.
A summary report is based on a list view. You want to summarize the records in a found set, grouping them together. This doesn't work from the perspective of the parent. You don't want to group classes together, you want to group dates together. Therefore, you want each record to be a date, not a class. So you base the report on the dates.
Sent from my iPad
I understand. Thank you. It’s now clear that I have a Many-to-Many relationship. One class could relate to many days in DATES and one day in DATES could relate to many CLASSES so I need a JOIN table to hold ID’s from both tables.
FYI - I created a couple of scripts to automate the process of creating Join records. One script uses a List to create a found set of Dates based on the criteria for each Class. Another script imports the record ID’s for the found set and populates the Class foreign key.
Thanks again for your insight and help.