Best Practices for Reporting

  • Article

The following are some recommended practices:

  • Use Existing Reports as Templates: Using existing reports that present either similar data, or data in a similar form, makes for a much easier experience with authoring new reports, because the new reports can leverage the query and formatting from the existing reports. An administrator can export a report definition by choosing the Properties tab, while viewing a report, and then clicking on the Edit link in the Report Definition section, under the General sub-tab. This link allows the report definition file to be saved as a .rdl file that can later be imported into a report project.

  • Report Data Collection: The rules that collect the data required by reports should be clearly marked as such by prefixing the rule name with the words "Report Data Collection -". Also, reports should clearly document the rules required to collect data for the reports. This should be done in the Help documentation, as well as in the report itself--within the no-rows property of tables and charts. Doing so allows users to enable and disable the appropriate rules for reports.

  • Report Widths: For best results, reports should be designed so that they fit within a 1280x1024 resolution screen. This is achieved by restricting the horizontal page width to no more than 12 inches. Also, the report page size property needs to be set appropriately so that the report displays correctly when exported to formats such as PDF and TIFF. Not setting the page size property correctly could cause the report to become unreadable because of data being split into multiple pages, or due to excessive white space.

  • Report Parameter Documentation: Reports should clearly document parameter values chosen by the user, so that this information is available when the report is exported to an external data format-- without the context of the browser.

  • Local date/time considerations: All date/time data in the MOM database is stored in UTC time. Reports should convert this time to the appropriate local time before displaying this data in reports. Several of the most commonly used views contain additional properties that indicate the local date/time in the time zone that the DW server is located in, for the most commonly used properties.

  • Separating labels text from expressions: Separating localizable text into separate fields from expressions makes it easier to localize a report into different languages, because only the text fields must be localized.