Microsoft Office 2000/Visual Basic Programmer's Guide |
Most solutions that manage data include some way of presenting that data in reports. By creating reports, you can turn raw data into usable information.
There are lots of different ways to present data in an Office solution. How you build reports depends on how your solution is designed and where the data is stored. For example, suppose that Access forms the basis for your solution, so that users interact with data through Access forms and data access pages. However, your users may prefer to view and manipulate data in Excel so that they can create custom reports with maximum flexibility. In that case, you may want to export data from Access to Excel. On the other hand, if your data is stored in an Access or SQL Server database but your solution is Excel-based, you probably want to write code in Excel to display the data.
When you design a custom report, you should ask yourself these two questions:
A static report is not linked to the data source. In order to display updated data, you must re-create a static report. This approach is fine for data that does not change frequently, or reports that are re-created only occasionally, such as weekly or monthly. One advantage to a static report is that it's easy to alter the report's data source. For example, you can enhance the report by adding additional fields before you re-create it. Or perhaps you need to allow the user to choose which fields are to be included in the report each time it is created.
A dynamic report remains linked to the data source, and the user can view updated data by refreshing the report. Dynamic reports are easy to create, but you need to ensure that the data source will be available when the user refreshes the report. If you change the structure of a dynamic report’s data source (for example, by adding a new field), you need to re-create the report. Refreshing a report will not display new fields added to the underlying query
If the data to be displayed in a report is fairly simple, you can present it as a read-only report — that is, a report that the user can view but not modify after it’s been created. Read-only reports include Access reports, report snapshots, and objects saved as HTML. Of course, you can write code that sorts, filters, or otherwise customizes a read-only report as it is being created. A customer phone list is an example of a report that could be a read-only report.
If the data to be presented is more complex, you may want to create a report that users can manipulate to display the data the way that they want it. Excel is an ideal tool for this — you can build a report including data lists, PivotTable reports, and charts, all of which the user can alter in the Excel user interface.
The following sections outline some common approaches for presenting data in an Office solution.