When are Subreports Necessary?
If you aren’t familiar with subreports, it can be a little confusing at first to determine when they are needed. I said in the introduction that a subreport is useful for printing data from multiple groups of tables, but we already know that a regular report can print from a group of tables. So what makes subreports different?
As a general rule, subreports are needed when you want to print out more than one set of unlinked detail records. For example, consider an employee payroll report that shows a list of an employee’s paychecks for the year. In this report, you would only need a single report because there is only one set of detail records to print. But let’s change the report requirements so that you also want to show a salary history for each employee. The salary history pulls data from a different table than the payroll history and there is also more than one salary record for most employees. Thus, this report now needs to show two types of lists for each employee. To make this work you would add a subreport that just shows the employee salary history. By adding a subreport, you have now delegated the two lists to be on their own report. The payroll history is printed by the main report, and the salary history is printed by the subreport.
If you are familiar with database technology, another way to think of this in “geek speak” is that subreports are necessary when you have tables with multiple one-to-many relationships. “One-to-Many” refers to having a main table (the parent table) where each individual record can have multiple matching records in a secondary table (the child table). For example, a Customer table and an Address table can have a one-to-many relationship. The parent table, Customer, has one record for each customer. The child table, Address, has multiple records for each customer because a customer can have multiple offices and shipping locations. This is also referred to as a parent-child relationship and the Customer ID field would be the linking field.
