If you have Statistic FIELDS you will get Min/Max/Count ... for found count of records.
Get(FoundCount) will get you current found records
Thank you Johann!
I would like to avoid creating Statistic Fields, fearing that this might slow down considerably the solution. I would have to create 5-6 fields per variable, for about 50 variables, this would be about 250-300 statistic fields.
By doing this via scripts, I would have 1 script / analysed variable, which would be calculated only on demand.
Statistic fields only slow things down if they appear on the layout. If you dont show them but instead just get there data into $$ you can just show merge variables in your layout
1 of 1 people found this helpful
Summary fields are empty, and uncalculated, until they are used. They won't impact your solution's performance just by existing. They are also far more flexible than the route you're thinking of going down. For instance, let's say you wanted Count, Min, and Max for each value of a given field (like salesman). If you use a subsummary report, you could place your Count summary field, Min summary field, and Max summary field in a subsummary part, and those values would be calculated for each salesperson AND you could get other totals and a grand summary if you needed.
If you have all of those summary fields in a table, and they are only used on summary layouts, they don't hurt performance at all, and ON those layouts, they are incredibly easy to use and always accurate.
Before you go down the route of adding a self-join you won't need and creating a big script...study up on subsummary reports. With one subsummary report, you could sort by salesperson and get all of the breakdowns by that, then sort by state and get all of the breakdowns by that, and then...whatever you want.
My two cents.
FM can perform SQL queries on its own tables. You might consider using the aggregate functions available there, although it doesn't have standard deviation.