General approach to reporting

Discussion created by davehob on Feb 29, 2012
Latest reply on Mar 3, 2012 by davehob

In the solution that I’m working on, the reporting function is very weak, and I’m looking at ways to improve it. The reports currently use a lot of very slow finds, dozens of unstored calcs in the data file itself, and some very inflexible layouts.


A typical reporting requirement is for a month-by-month analysis of activity at our community centre, with various sub-totals, cross-tab presentation, etc.

One route I’m thinking of going down is having a separate table (in the Interface file) for stuff to be included in the report (records within a certain date range, for example), and doing an import of qualifying records into that table. That way, I can do all the calculations in the “report records” table, keeping things cleaner (and quicker) in the data file, holding only the meaty data in the data table, with all the unstored calcs etc. in the temporary table, doing their stuff only when actually needed. Once the report has run, I can delete the records in the “report records” table.


Are there any pitfalls to this approach that I should be aware of? Or other recommendations for building a reporting sub-system that is robust, flexible and efficient? (The reference books that I use are quite light on this side of things – if anyone can point me to a good resource, that would also be really appreciated.)


Thanks in anticipation,