Page vs RDL vs Section Reports in a .NET C# Application

April 18 2022

ActiveReports.NET provides three different reporting formats in just one .NET reporting tool. These report types allow you to create practically any type of report for your business needs. This not only provides more options for reporting and report layout but also a better value for money.

Why a Reporting Tool?

Collecting and organizing data is one of the most cumbersome tasks for most of us. A reporting tool doesn't just make this easier but also more organized and presentable. With a reporting tool, we need to provide the data source, set a few properties here and there, and data can be represented in groups, charts, tables, tablices, etc. Hence, a format that is far more palatable and easier to comprehend than raw data in a grid or spreadsheet. ActiveReports.NET offers this and much more as an integrated ad hoc report designer for Microsoft .Net developers. And as mentioned above, it also provides multiple report types to fit the needs of one and all.

Section-Based Reports

Section-based reports are the traditional banded reports with predefined sections: Page Header, Detail, and Page Footer. From Invoices to Budget and Sales-Accounting reports or even a school report card, virtually any report can be divided into these three basic sections. Reporting eventually reduces to just binding data to controls or providing a data source to fetch from and leaving the reporting engine to render beautiful and professional reports. We can further customize these reports using code/scripts in the report events with Section Reports. Section Reports' detailed concepts (structure, events, etc.) are discussed here.

Strengths:

Traditional banded report section
Provides ultimate flexibility - Event driven reporting, embedded scripts to control runtime behavior
Suitable for developers as opposed to end-user, ad hoc, reporting

User Scenario: Let's consider a case of an e-commerce store that needs to generate a simple packing slip based on the products sold. The report will start with the name of the store, its address, and contact details, followed by a summarized view of the total amount due before taxes, taxes involved, and the amount due after taxes. It will then display the list of all purchased items, their quantities, and the final price. This list may go on for several pages, and finally, the total amount, calculation for taxes, and the final amount due will be displayed.

The design of the report would be in the following manner:

ReportHeader would have the fields displaying: the name of the store, its address, and contact details
Detail would have the fields displaying: purchased items, their quantity, and the final price
ReportFooter would have the fields displaying: the total amount, calculation for taxes, and the final amount due

The final report would look like the following:

Report Design

Page-Based Reports

Sometimes designing reports requires that each page be designed to a specific need. Page-based reports are the perfect solution in such scenarios because they allow the developer to control the layout. With Page Reports, each page is an object that holds controls of fixed size and position to show data from a data source.

Because you're designing the layout for each page, each page can have different controls, sizes, layout orientation, margins, and more. This layout produces a 100% WYSIWYG output. While not event-driven like Section Reports, Page and RDL reports support Expressions that allow you to control the dynamic runtime behavior of the report.

Strengths:

Each Page of the report can have its own design
Offers more powerful controls compared to Section Reports (Table, Tablix, Maps, TOC, etc.)
Great for fixed layout reports such as legal documents
WYSIWYG layout
The simplified design makes it ideal for ad hoc reporting by non-technical users

User Scenario: Let's again talk about the e-commerce store above. This time we'll take a different perspective on handling the billing. Every time a bill is generated, it will have the name of the store, its address, and contact details at the top of each bill. It will then display the list of items purchased by the customer and the sum of the bill.

A desirable situation would be to have two copies of this report: one for the store and one for the customer. The store's copy will have a 'Merchant's Copy' message and might also include the customer's detail (name, contact number) for further follow-up.

On the other hand, the customer's copy would have a 'Customer's Copy' message, the store's toll-free helpline number, and other custom messages. In such a scenario, a report with two pages (one for the customer's copy and the other for the store's copy) could be created, with each page having a different layout. The final report, in this case, would look like the following:

Page-Based Report

RDL Reports

RDL, or Continuous Page Layout (CPL), Reports are the most common that combine flexibility and power in one. With RDL Reports, controls can grow vertically and horizontally, whereas, in Page Reports, you define the maximum size of the control. RDL Reports are ideal for showing data from different data sets and when you do not need to control where the data appears on the page. Hence, RDL Reports offer the best of both worlds.

Strengths:

RDL Reports, like Page Reports, are more graphical and easier to design for non-technical users. Therefore, both report types are ideal for ad hoc reporting
Controls and data regions grow to accommodate the data
Flexible, code-free, report design capabilities
Powerful reporting features (Layers, Group Editor, Reports Library)
Powerful controls (BandedList, FormattedText, Table, Tablix, Charts, and more)

User Scenario: Considering the e-commerce example again, the online store wants to create an annual report highlighting its total sales that year (by Category), including a list of its five most loyal customers and five most valuable employees. Designing this report will be a breeze with RDL Reports.

The final report would look like the following:

RDL Report