What you want is possible, but I suggest an easier way:
Base your layout on donations. Perform a find to find the donation records that you want to see--whether just by date or for just one donor and a date (or range of dates).
Sort the records by date.
If you set up a sub summary layout part "when sorted by date" and remove the body layout part from this layout you can get a report that lists one row for each date with your summary field reporting the subtotal for that date if you place the summary field inside the sub summary layout part.
A filtered portal could be used for this purpose if you insist, but the set up and data model is more complex than just using a layout based on donations for this purpose. So if you really want that portal approach, let me know and I'll describe how to set up a filtered portal with a self join and your summary field to get one potal row per date with the desired subtotal.
When I setup a layout as you suggest, I just get the total for all donations and only the first date. I did delete the body section. Does that tell you anything helpful?
Thanks, in advance.
Did you add a sub summary part?
Did you sort your records?
Is the summary field located inside the sub summary part?
Using such a layout usually requires a script that:
Enter find mode
Changes layouts to the report layout
Finds the records
You use a script to find the records because often the fields you want to use for finding the records aren't accessible on the report layout in most cases. You enter find mode first before changing layout to avoid a "performance hit" where you might otherwise end up with a summary field trying to unnecessarily compute a grand total before you can find the actual records that you want for your report. You have to sort the records by the field specified in the sub summary part or the sub summary part will not be visible.
I want to learn more about why you stated, "You enter find mode first before changing layout to avoid a "performance hit" where you might otherwise end up with a summary field trying to unnecessarily compute a grand total before you can find the actual records that you want for your report."
Not just for this situation, but for implications of this concept throughout FMP.
Switching to a layout in a hosted solution can cause the server to send a large number if records to the client. If the there is a summary field or other object that computes aggregate values, these then start to calculate.
This doesn't happen if you are in find mode. In many layouts/for many networks, this does not produce a noticeable delay, but since it is possible, it makes sense to switch mode before changing layouts.
That's great information. After, you enter find mode and switch layouts, then do you perform a find to only get the records you need? What does that look like in a script?
Yes, for years I wrote scripts like this:
Go to layout
enter find mode [ ] -- No pause, no stored criteria
set field --- use set field to set up criteria and find operators used in the find
Set Error Capture [on]
Perform find [ ] -- No stored criteria here either
But lately, I'm doing it this way:
Enter Find Mode [ ]
Go to Layout
and so forth...