Delivering Reports

Troubleshooting

Printed Reports Show Only a Single Record

Sometimes, my printed reports contain only the first record of data. Why is that?

Chances are that your print settings are configured to print the current record rather than the current found count. When printing from a List view, be sure to select the Records Being Browsed option. This configuration can be specified within a script, so be sure to set your print scripts to use this configuration as well.

Slow Generation of Subsummary Reports

I have built several subsummary reports, but many of them take quite a while to generate. Is there anything I can do to speed them up?

This is a common source of performance issues many developers face. Various factors can influence the time it takes to generate a subsummary report. The most important of these is the size of the found set. A subsummary report over a found set of 50,000 records takes considerably longer to generate than one with 100 records. Another factor is the amount of summarization the report performs: A report with one summary field will generate faster than one with a dozen.

Consider what a subsummary report is doing in combination with summary fields: It is synthesizing data across multiple records dynamically. In other words, it is calculating up-to-date information based on your found set, sort criteria, and so on. This information is difficult to "pre-bake" (by having it be already calculated or indexed), so FileMaker (and other database technologies) has to generate this information on demand.

Another potential bottleneck is the complexity of the summarization. Summary fields that operate on plain number fields generally perform better than summary fields that operate on calculations that return number results. This is especially true if the calculations contain complex logic or aggregate functions that operate on large recordsets. It's even more true if any of the calculations is unstoreda performance drain you should strive to avoid if at all possible.

Unfortunately there's no magic fix here. Subsummary report performance depends entirely on how a given database is structured, on the needs of the organization it serves, and on the hardware and network on which it is deployed. General rules of thumb are to avoid using unindexed fields for sorting and finding, and to keep the number of summary type fields to a required minimum.

Beyond that, there are a few things you might try to improve the performance of subsummary reports by building routines that rely less on dynamic, on-demand information. The first is to automate the reports to run during the middle of the night; you can view the results as a PDF in the morning. Another option is to pre-summarize some of the data. This might involve running a script to set plain number fields to the result of complex calculations. Or you might create utility tables where you can store summarized data. For instance, every month you might run a month-end closing routine that posts monthly totals for each product or salesperson to a utility table. Then, rather than having summary reports based on granular data, you can run reports against the pre-summarized data.