Microsoft Access 2010 : Report Properties and Why to Use Them, Basing Reports on Stored Queries or Embedded SQL Statements

You can modify many different properties on reportsto change how the report looks and performs. Like form properties,report properties are divided into categories: Format, Data, Event, andOther. To view a report’s properties, you first select the report,rather than a section of the report, in one of two ways:

• Click the report selector (see Figure 1 ), which is the small gray button at the intersection of the horizontal and vertical rulers.

  Figure 1. The report selector.

  

• Select Report from the drop-down list box in the Properties window.

After you have selected a report, you can view and modify its properties.

Working with the Properties Window

To select a report and open the Properties window atthe same time, you double-click the report selector. When you select areport, the Properties window appears, showing all the propertiesassociated with the report. A report has 77 properties available on theProperty Sheet (there are additional properties available only fromcode), broken down into the appropriate categories in the Propertieswindow. Fifty of the properties relate to the report’s Format, Data,and the properties on the Other tab; the remaining 27 relate to theevents that occur when a report is run. The Format, Data, and Otherproperties are described here.

The Format Properties of a Report

Areport has the following 29 Format properties for changing the report’sphysical appearance. The text that follows explains many of the Formatproperties:

• Caption — The Caption property of a report is the text that appears in the Report window’stitle bar when the user is previewing the report. You can modify it atruntime to customize it for a particular situation.

• Default View — The Default View determines whether a report is opened in Report view or Print Preview.

• Auto Resize — The Auto Resize property was introduced with Access 2002. Its setting determineswhether a report is resized automatically to display all the data onthe report.

• Auto Center — You use the Auto Center property, which was introduced with Access 2002, to designate whetheryou want the Report window to automatically be centered on the screen.

• Page Header and Page Footer — The Page Header and Page Footer properties determine on what pages the Page Header and Page Footersections appear. The options are All Pages, Not with Rpt Hdr, Not withRpt Ftr, and Not with Rpt Hdr/Ftr. You might not want the page headeror page footer to print on the report header or report footer pages,and these properties give you control over where those sections print.

• Grp Keep Together — In Access, you can keep a group of data together on the same page by using the Grp Keep Together property. The Per Page setting forces the group of data to remain onthe same page, and the Per Column setting forces the group of data toremain within a column. A group of data refers to all the data within a report grouping (for example, all the customers in a city).

• Border Style — The Border Style property was introduced with Access 2002. Like its form counterpart, itis far more powerful than its name implies. The options for the Border Style property are None, Thin, Sizable, and Dialog. If the Border Style property is set to None, the report has no border. If the Border Style property is set to Thin, the border is not resizable; the Size commandisn’t available in the Control menu. This setting is a good choice forpop-up reports, which remain on top even when other forms or reportsare given the focus. Having the Border Style property set toSizable is standard for most reports. It includes all the standardoptions in the Control menu. The Dialog setting creates a border thatlooks like the border created by the Thin setting. The user can’tmaximize, minimize, or resize a report with the Border Style property set to Dialog. After you set the Border Style property of a report to Dialog, the Maximize, Minimize, and Resize options aren’t available in the report’s Control menu.

• Moveable — The Moveable property determines whether the user can move the Report window aroundthe screen by clicking and dragging the report by its title bar.

The Report’s Data Properties

A report has the following six Data properties, which are used to supply information about the data underlying a report:

• Record Source — The Record Source property specifies the table or query whose data underlies the report.You can modify the record source of a report at runtime. This featureof the Record Source property makes it easy for you to create generic reports that use different record sources in different situations.

• Filter — The Filter property allows you to open a report with a specific filter set. Iusually prefer to base a report on a query rather than apply a filterto it. At some times, however, it’s more appropriate to base the reporton a query and then apply and remove a filter as required, based on thereport’s runtime conditions.

• Filter On Load — The Filter On property determines whether a report filter is applied. If the Filter On Load property is set to No, the Filter property of the report is ignored.

• Order By — The Order By property determines how the records in a report are sorted when the report is opened.

• Order By On Load — The Order By On Load property determines whether the Order By property of the report is used. If the Order By On Load property is set to No, the report’s Order By property is ignored when loading the report.

• Allow Filters — The Allow Filters property determines whether the report data can be filtered.

Other Properties of a Report

A report has 15 Other properties (see Figure 2 );these miscellaneous properties, some of which are described in thefollowing text, enable you to control other important aspects of areport:

• Record Locks — The Record Locks property determines whether Access locks the tables used in producing areport while it runs the report. The two values for this property areNo Locks and All Records. No Locks is the default value; it means thatno records in the tables underlying the report are locked while thereport is being run. Users can modify the underlying data as the reportis run; this can be disastrous when running sophisticated reports. Ifusers can change the data in a report as the report is being run,figures for totals and percentages of totals are invalid. Althoughusing the All Records option for this property locks all records in alltables included in the report (thereby preventing data entry while thereport is being run), it might be a necessary evil for producing anaccurate report.

• Date Grouping — The Date Grouping property determines how grouping of dates occurs in a report. The USDefaults setting means that Access uses United States defaults forreport groupings; therefore, Sunday is the first day of the week, thefirst week begins January 1, and so on. The Use System Settings settingmeans that date groupings are based on the locale set in the ControlPanel’s Regional Settings, rather than on U.S. defaults.

• Pop Up — The Pop Up property determines whether a report’s Print Preview window opens as apop-up window. In Microsoft Access, pop-up windows always remain on topof other open windows.

• Modal — The Modal property instructs Access to open the Report window in a modal ormodaless state. The default is No, meaning that the window will not beopened as modal. A modal window retains the application program’s focusuntil the window receives the user input that it requires.

• Tag — The Tag property stores information defined by the user at either design timeor runtime. It is Microsoft Access’s way of giving you an extraproperty. Access makes no use of this property; if you don’t takeadvantage of it, it will never be used.

Basing Reports on Stored Queries or Embedded SQL Statements

Basing Access reports on stored queries offers two major benefits:

• The query underlying the report can be used by other forms and reports.

• Sophisticated calculations need to be built only once—they don’t need to be re-created for each report (or form).

In earlier version of Access, reports based on stored queries open faster than reports based on embedded SQL statements. This is because when you build and save a query, Access compiles and creates a query plan. This query plan is a plan of execution that’s based on the amount of data in the query’s tables as well as all the indexes available in each table. In early versions of Access, if you ran a report based on an embedded SQL statement, the query was compiled, and the query plan was built at runtime, slowing the query’s execution. With Access 2010, query plans are built for embedded SQL statements when a form or report is saved. Query plans are stored with the associated form or report.

So what are the benefits of basing a report on a stored query instead of an embedded SQL statement? You may want to build several reports and forms, all based on the same information. An embedded SQL statement can’t be shared by multiple database objects. At the very least, you must copy the embedded SQL statement for each form and report you build. Basing reports and forms on stored queries eliminates this problem. You build the query once and then modify it if changes need to be made to it. Many forms and reports can all use the same query (including its criteria, expressions, and so on).

Reports often contain complex expressions. If a particular expression is used in only one report, nothing is lost by building the expression into an embedded SQL statement. On the other hand, many complex expressions are used in multiple reports and forms. If you build these expressions into queries on which the reports and forms are based, you have to create each expression only one time.

Although basing reports on stored queries offers several benefits, it also has downsides. For example, if a database contains numerous reports, the database container becomes cluttered with a large number of queries that underlie those reports. Furthermore, queries and the expressions within them are often very specific to a particular report. If that is the case, you should opt to use embedded SQL statements rather than stored queries. As a general rule, if several reports are based on the same data and the same complex calculations, you should base them on a stored query. If a report is based on a unique query with a unique set of data and unique calculations, you should base it on an embedded SQL statement.