So can you reproduce this by selecting sort from the Records menu and changing the fields specified for the sort order?
What happens if you set up your sort button to perform a script that sorts the records followed by a Refresh window script step? Does that make a difference?
Yes. I did this:
- Used the Button to sort by Order/Item
- Used the Records/Sort menu to add Department to the top of the sort
- Result was the same - Value for the summary field quantity for the order changed to 18
Also see attachment of script steps that fix this problem in the scripted sort.
By the way, is this conversation publicly available. Not sure if I need to remove customer name or not from these screen shots.
By the way, a Refresh Window script step does not fix this issue
This is a public forum. Don't show anything you don't want the whole world to see.
Just out of curiosity, did you try using Refresh Window [Flush cached join results]? I can't really recommend that as a general purpose work around but if it corrects the issue as well as the zoom does, then it might provide a useful clue to the folks that need to fix it.
Also, if you create a new blank layout without copying anything from this layout--with just enough detail to test this issue, does it reproduce the same behavior? That test would be to rule out possible corruption of your layout being the cause of this--something that I've never seen in any of my own summary reports.
Refresh Window (Flush Cache Join) does not fix the problem. Seems like only toggling to layout mode then browse, or toggling Zoom level will cause the calculation to correct.
I will try creating a new blank layout as suggested.