Master Reports are like dynamic templates you can design for use with content reports. This assists users in creating reports that share common elements such as a logo in the page header or a web site link in the page footer. You design the master report with controls, code, data sources, and layout properties that cannot be modified from content reports.
Master Reports differ from templates in that they are loaded each time the report is executed. Therefore, you can modify a master report and the changes to the master report automatically appear in any reports that reference it.
You can also save and execute shared master reports on ActiveReports Server while working with the Visual Studio designer or the ActiveReports End User Designer control. Shared master reports are RDLX master reports (*.rdlx-master) that are hosted on an instance of ActiveReports Server. Once you save the master report on the server and use it to create a content report, ActiveReports automatically marks the report as a remote report. You can set a master report that is stored on the server using the Set MasterReport>Open From Server option in the Report Menu.
Shared master reports offer the advantages of a local master report, plus:
When designing a master report, you use controls, code, data sources, and layout properties in the same way that you do in a normal report. A master report is valid on its own, and can be run without a content report. To prevent end users from modifying a master report, you can set permissions on the file to Read Only for that user or group.
In an RDL report, you can create a master report by saving it as an RDLX-master file. You can then apply it like a template to content reports.
A ContentPlaceHolder control appears in the toolbox when you convert an RDL report to a Master Report. This control defines regions where users can add content after applying a master report template.
The reports to which you apply the master report are content reports. A content report is not valid on its own, and cannot be run without its specified master report.
When the user creates a new report and sets a master report on it, the design view is effectively the opposite of the design view of the master report. Any report controls overlaid by ContentPlaceHolder controls are not visible in the content report at design time, but are visible at run time. These are the only areas where users can add report controls.
While designing the content report the user can
While designing the content report the user cannot
This is what happens behind the scenes when you run a content report.
When you run a content report, the content report and its master combine to form an aggregated report definition. Using the ReportDefinition API, you can save this aggregate at run time as a third report definition which has no master or content report. Once this aggregate is saved as a normal report definition (*.rdlx file) you can edit it like any other report definition.