Overview: Getting Started with Seal Report

Source: Dev.to

Seal Report is an open‑source reporting engine designed for developers who prefer working close to their data layer instead of relying on heavyweight BI platforms. It builds on SQL queries, metadata‑driven models, Razor scripting, and flexible filters to produce dashboards, pivot tables, exports, and embedded reporting workflows inside .NET environments.

This series walks through the practical steps required to move from a simple SQL‑backed table toward a structured reporting layer capable of supporting shared filters, dynamic joins, database‑level restrictions, and authentication‑aware execution. Each article focuses on one capability that gradually expands what a Seal Report installation can do.

1. Building Your First Data Table from SQL Server

The starting point of any Seal Report setup is understanding how models and elements translate into executable SQL. This article demonstrates how to:

• Define a data source
• Expose tables through metadata
• Assemble a simple report that renders a structured dataset

Once this foundation is clear, filters, joins, and restrictions all build on the same model‑driven execution flow, making it easier to validate connectivity to an existing SQL Server environment.

2. Static and Dynamic Select Lists

Filters become more useful when their possible values are controlled instead of entered manually. This article explains how select lists can be defined:

• As fixed enumerations (static)
• Generated dynamically from database queries (dynamic)

Reusable select lists improve usability and consistency across reports, especially when several reports depend on the same reference data.

3. Applying Dependent Filters

Dependent filters allow one selection to influence the available values of another, turning a flat filter interface into a guided navigation experience. Benefits include:

• Reduced incorrect combinations
• Easier exploration of hierarchical relationships (e.g., country → city, category → product group)

The approach creates a more intuitive user experience.

4. Applying Custom Joins

When a database schema isn’t designed with reporting in mind, custom joins let you adapt metadata relationships without altering the underlying database. By defining join logic directly inside Seal Report you can:

• Support conditional relationships
• Create alternative join paths that reflect reporting requirements

This flexibility is valuable for legacy schemas or environments where database changes are difficult.

5. Mapping Restrictions to SQL User‑Defined Functions

Restrictions can be moved closer to the database layer by delegating filtering logic to SQL user‑defined functions. Instead of embedding conditions in report definitions, Seal Report can call centralized logic maintained within the database, which:

• Keeps metadata cleaner
• Ensures consistency between reporting behavior and application‑level filtering rules

Ideal for environments with row‑level visibility already driven by database logic.

6. Sharing Filters Across Multiple Models

As reports incorporate multiple datasets, maintaining consistent filtering becomes essential. Shared filters synchronize parameter values between models so that tables, pivot views, and charts all react to the same selections, resulting in:

• Predictable dashboards
• Easier maintenance when visual components share a reporting context

7. Creating a Pivot Table with Custom Filters

Pivot tables add an analytical dimension by allowing measures to be grouped and compared across multiple axes. Combined with custom filters, they enable:

• Summarization of trends
• Highlighting relationships between dimensions in a compact layout

Pivot tables transform operational data into exploratory dashboards.

8. Authentication Providers

Authentication providers let Seal Report retrieve execution context from external identity systems (APIs, tokens, session‑based environments). With user identity available during report execution, filtering logic can:

• Enforce row‑level visibility
• Apply tenant‑specific access controls

Crucial for embedding Seal Report inside existing web applications where reports must respect the host system’s security boundaries.

---

Taken together, these articles describe a progression from a basic SQL‑backed report toward a flexible reporting layer that supports reusable filters, database‑driven restrictions, adaptive joins, synchronized dashboards, and authentication‑aware execution inside real‑world .NET environments.