Based on your screenshot, it looks like you may be storing all the data in a single table? I'd suggest creating multiple tables for Meetings and Members. Then, you relate these tables together where one Meeting would have many Members.
And I don't want to trip you up here … but, consider a third table too, commonly called pivot table or join table in the middle. That would allow you to model this where one Member may have multiple Meetings.
For example, you'd create a "parent" Meeting record with a date/time and other details (it looks like you store Meeting Type). Then, you add "child" Member records to store who was present.
And depending on your use case, every Meeting may not be applicable to every Member. So, perhaps you pivot table could be modeled as "Invites" and then it that table you'd store whether that Member was present.
- One Meetings has many Invites
- One Invite has one Meeting (Related Meeting)
- One Invite has one Member (Related Member
- One Member has many Invites
Once the three tables are setup and related, you'd create a summary field on the Meetings table to count the number of Invites (from the pivot table) and a second summary field on the Meetings table to count the number of Invites (also from the pivot table) where the "Attendance box is checked." Then, you'd need one more summary field on the Meetings table to divide the two numbers, displaying them as a percentage.
You could repeat the summary field process from the context of the Members table. Summarize (count) their respective number of Invites, count Invite Attendance and divide to get their Attendance rates. Then, you'd run your report from the context of the Members table to get the results you are after!
If you choose to go this route, you have a much more flexible system that doesn't require manual maintenance of messing with formula fields each time a meeting was added nor require extra fields to be added for new meetings, resulting in "wide tables" vs. "tall tables."
Maybe that helps? Or maybe that's overkill.
Marks solution would works too, it's just more rigid and maybe that's fine your project.
------------------------------
Brian Seymour
------------------------------
