DEV Community: Vlad Ganușceac

Overview: Getting Started with Seal Report

Vlad Ganușceac — Sat, 25 Apr 2026 08:01:21 +0000

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.

Below is a guided overview of those steps and how they connect together.

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, and assemble a simple report that renders a structured dataset. Once this foundation is clear, the rest of the framework becomes easier to navigate because filters, joins, and restrictions all build on the same model-driven execution flow. It’s the natural entry point for anyone setting up their first reporting workspace or validating connectivity to an existing SQL Server environment.

2. Static and Dynamic Select Lists

Filters become much more useful when their possible values are controlled instead of entered manually. This article explains how select lists can be defined either as fixed enumerations or generated dynamically from database queries. Once introduced, they quickly become reusable building blocks that improve both usability and consistency across reports. They are especially helpful when several reports depend on the same reference data or when filter inputs must remain constrained to valid business values.

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. Instead of presenting users with unrelated dropdown lists, Seal Report can narrow options dynamically based on earlier selections. This approach reduces incorrect combinations and makes complex datasets easier to explore. It becomes particularly useful when working with hierarchical relationships such as country–city structures or category–product groupings.

4. Applying Custom Joins

Not every database schema is designed with reporting in mind. Custom joins provide a way to adapt metadata relationships without modifying the underlying database structure. By defining join logic directly inside Seal Report, it becomes possible to support conditional relationships and alternative join paths that better reflect reporting requirements. This flexibility is especially valuable when working with legacy schemas or environments where database changes are difficult to introduce.

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 directly inside report definitions, Seal Report can call centralized logic maintained within the database itself. This keeps metadata cleaner and ensures consistency between reporting behavior and application-level filtering rules. It is particularly effective in environments where row-level visibility already depends on database-driven access logic.

6. Sharing Filters Across Multiple Models

As reports begin to include multiple datasets, maintaining consistent filtering across them becomes essential. Shared filters make it possible to synchronize parameter values between models so that tables, pivot views, and charts all react to the same selections. This keeps dashboards predictable and easier to maintain, especially when several visual components depend on the same reporting context.

7. Creating a Pivot Table with Custom Filters

Pivot tables introduce an analytical dimension to Seal Report by allowing measures to be grouped and compared across multiple axes. Instead of presenting raw datasets only as tables, reports can summarize trends and highlight relationships between dimensions in a compact layout. Combined with custom filters, pivot tables become a powerful way to transform operational data into dashboards suitable for exploration and decision support.

8. Authentication Providers

Authentication providers allow Seal Report to retrieve execution context from external identity systems such as APIs, tokens, or session-based environments. Once user identity becomes available during report execution, filtering logic can adapt dynamically to enforce row-level visibility or tenant-specific access. This capability is particularly important when embedding Seal Report inside existing web applications where reports must respect the same security boundaries as the host system.

Remarks

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.

Getting Started with Seal Report: Authentication Providers

Vlad Ganușceac — Mon, 20 Apr 2026 13:42:11 +0000

One thing is to create report definitions and link them to data sources; another is to apply authorization to those reports.

By default, the Seal Report Repository folder contains a Security subfolder. This folder includes authentication providers and a Security.xml file that defines how user authorization is handled for each instance of the report server.

The hierarchy looks like this:

. Seal Report Repository
|__ Security
   |__ Security.xml
   |__ Providers
      |__ Basic Authentication.cshtml
      |__ Basic Windows Authentication.cshtml
      |__ Claims Principal.cshtml
      |__ Database Authentication.cshtml
      |__ Integrated Windows Authentication.cshtml
      |__ JWT.cshtml
      |__ LDAP Authentication.cshtml
      |__ No Security.cshtml
      |__ OpenId.cshtml

In this post, we will review each of these authentication providers and examine the flow used to retrieve report results.

Inspecting the `Security.xml` File

The file responsible for managing authorized access to Seal Report Server resources has the <SealSecurity> root element.

There are four main sections within this root element:

<ProviderName>
<Parameters>
<Groups>
<Logins>

If you are using a custom security provider, the <UseCustomScript> section will also appear.

Inside the ProviderName tag, one of the authorization methods available in the Providers subfolder must be specified (without the .cshtml file extension).

For example,

<ProviderName>OAuth</ProviderName>
<UseCustomScript>true</UseCustomScript>

The Parameters tag contains an array of <SecurityParameter> elements. Each security parameter represents a key–value pair.

For example,

<SecurityParameter>
   <Name>check_auth_url</Name>
   <Value>http://localhost:3000/auth/check_token</Value>
</SecurityParameter>

The Groups tag contains an array of <SecurityGroup> elements.

Each security group has:

a unique identifier
a display name
a set of folders that group members are allowed to access.

Additionally, permissions can be configured per security group. These permissions define whether members are allowed to:

view reports
download reports
edit reports
modify configuration settings

For example,

<Groups>
   <SecurityGroup>
      <GUID>fab75313-9be6-4d53-9545-781c2027f6f4</GUID>
      <Name>Administrator</Name>
      <Folders>
         <SecurityFolder>
            <Path>\PathToReportsFolder</Path>
         </SecurityFolder>
      </Folders>
      <Weight>1</Weight>
      <EditConfiguration>true</EditConfiguration>
      <DownloadUpload>Download</DownloadUpload>
      <Culture/>
   </SecurityGroup>
</Groups>

The Logins tag contains an array of <SecurityLogin> elements. Each element defines a user account with:

a unique identifier
user ID
password hash
display name
email address
associated security group IDs

For example,

<Logins>
   <SecurityLogin>
      <GUID>d8f5a54208af4d62a7c452e8d52ae659</GUID>
      <Id>username_here</Id>
      <Password>password_hash_here</Password>
      <Name>user_display_name_here</Name>
      <Email>user_email_here</Email>
      <GroupIds>
         <string>fab75313-9be6-4d53-9545-781c2027f6f4</string>
      </GroupIds>
   </SecurityLogin>
</Logins>

Understanding the structure and purpose of the Security.xml file is essential before exploring the available authorization providers in detail.

Basic Authentication Provider

The Basic Authentication provider validates users based on credentials entered in the Seal Report login screen and matches them against entries defined in the <Logins> section of the Security.xml file.

Its implementation is located in the following script:

Security/Providers/Basic Authentication.cshtml

During authentication, the provider uses the values entered by the user through the Seal Report Server interface:

WebUserName
WebPassword

These values are passed to the LoginAuthentication() method:

if (!user.LoginAuthentication(user.WebUserName, user.WebPassword)) {
    throw new Exception("Invalid user name or password");
}

The method validates the credentials against the users declared in the Security.xml file. If authentication fails, access to the report server is denied.

If authentication succeeds, the authenticated user inherits the security groups associated with the corresponding <SecurityLogin> entry. These groups determine access permissions to report folders and available operations such as viewing, downloading, or editing reports.

Additionally, the provider assigns the authenticated username to the current session:

user.Name = user.WebUserName;

This value is later used by the Seal Report Server interface when displaying information about the active user.

The Basic Authentication provider represents the most straightforward way to secure access to Seal Report Server resources when authentication is managed directly through the repository configuration stored in Security.xml.

Basic Windows Authentication Provider

The Basic Windows Authentication provider validates users using Windows credentials entered in the Seal Report login screen. The authentication process relies on Windows identity verification and optionally maps Windows groups to Seal Report security groups.

Its implementation is located in the following script:

Security/Providers/Basic Windows Authentication.cshtml

During authentication, the provider reads the credentials entered in the login interface through the WebUserName and WebPassword properties. These values are passed to the Windows authentication mechanism using the Impersonator.CheckWindowsLogin() method:

user.Identity = Impersonator.CheckWindowsLogin(
    user.WebUserName,
    user.Security.GetValue("default_domain_name"),
    user.WebPassword
);

If the authentication succeeds, a Windows identity is assigned to the current session and the username is stored in the active Seal Report user context:

user.Name = user.WebUserName;

After successful authentication, security groups are assigned either by matching Windows groups with Seal Report security groups or by assigning the default security group defined in the configuration. This behavior depends on the value of the add_windows_groups parameter declared in the provider settings.

If Windows group matching is enabled, the provider retrieves the user’s Windows groups and attempts to associate them with existing Seal Report security groups. Otherwise, the default security group is applied automatically.

If authentication succeeds but no matching security groups are assigned, the provider logs the detected Windows groups for diagnostic purposes and prevents access to report resources until group membership is resolved.

If Windows authentication fails, access to the Seal Report Server is denied.

The Basic Windows Authentication provider is typically used when Seal Report Server must authenticate users directly against Windows accounts entered through the login interface without relying on integrated domain authentication mechanisms.

Claims Principal Provider

The Claims Principal provider authenticates users based on the ClaimsPrincipal object available in the HTTP request context. This provider is typically used when authentication is already performed by an external identity platform such as Azure App Service or another middleware component that injects claims into the request pipeline.

Its implementation is located in the following script:

Security/Providers/Claims Principal.cshtml

During authentication, the provider retrieves the ClaimsPrincipal instance from the incoming HTTP request and extracts user identity information from its claims collection. The username is obtained from the claim of type name and assigned to both the WebUserName and Name properties of the active user session.

After the identity is resolved, the provider iterates through the security groups defined in Security.xml and assigns matching groups when the authenticated principal belongs to roles with corresponding names. If no matching groups are found, access to report resources is denied and a warning is written to the server log.

The Claims Principal provider is typically used when Seal Report Server operates behind an authentication-enabled hosting environment where user identity and role membership are already resolved before the request reaches the reporting layer.

Database Authentication Provider

The Database Authentication provider validates users by attempting a connection to a database using the credentials entered in the Seal Report login screen. Authentication succeeds if the database connection is successfully established.

Its implementation is located in the following script:

Security/Providers/Database Authentication.cshtml

During authentication, the provider uses the values entered through WebUserName and WebPassword to open a database connection based on the configured oledb_connection_string parameter. If the connection succeeds, the username is assigned to the active session and the default security group defined in the configuration is applied automatically.

The provider also allows security groups to be resolved dynamically from database queries if additional logic is implemented inside the authentication script.

The Database Authentication provider is typically used when user credentials are stored and validated directly within a relational database system accessible through an OLE DB connection.

Integrated Windows Authentication Provider

The Integrated Windows Authentication provider authenticates users based on the Windows identity already associated with the current HTTP request. This provider relies on IIS Windows Authentication and does not require credentials to be entered manually through the Seal Report login interface.

Its implementation is located in the following script:

Security/Providers/Integrated Windows Authentication.cshtml

During authentication, the provider retrieves the Windows identity from the WebPrincipal object available in the request context. If the identity is authenticated, the username is assigned to the active session and security groups are applied either by matching Windows groups with Seal Report security groups or by assigning the default security group depending on provider configuration parameters.

If the request does not contain an authenticated Windows identity, access to the Seal Report Server is denied and an error message indicates that Windows Authentication must be enabled in IIS.

The Integrated Windows Authentication provider is typically used when Seal Report Server is deployed inside a Windows domain environment where authentication is managed transparently by IIS.

JWT Provider

The JWT provider authenticates users based on a JSON Web Token received either through the SWILogin parameter or through the HTTP Authorization header using the Bearer scheme.

Its implementation is located in the following script:

Security/Providers/JWT.cshtml

During authentication, the provider retrieves the token from the request and validates it using the configured token_key parameter. After decoding the token payload, the expiration timestamp is verified against the current system time to ensure the token is still valid.

If the token is valid, the username and associated security group are extracted from the token payload and applied to the active user session. If the token is missing or invalid, an alternate credential-based authentication flow may be executed depending on the provider configuration.

The JWT provider is typically used when Seal Report Server is integrated with external authentication services that issue signed tokens representing authenticated user sessions.

LDAP Authentication Provider

The LDAP Authentication provider validates users against an LDAP directory service using credentials entered in the Seal Report login interface.

Its implementation is located in the following script:

Security/Providers/LDAP Authentication.cshtml

During authentication, the provider creates an LDAP connection using the configured server name, port number, authentication type, and SSL settings. The credentials entered through WebUserName and WebPassword are used to bind to the LDAP server.

If the bind operation succeeds, the username is assigned to the active session and the default security group is applied automatically. Additional logic may be implemented to retrieve group membership information directly from the LDAP directory.

The LDAP Authentication provider is typically used when user credentials are managed centrally within directory services such as Active Directory or other LDAP-compatible identity providers.

No Security Provider

The No Security provider allows unrestricted access to the Seal Report Server by automatically assigning the default security group without performing any authentication checks.

Its implementation is located in the following script:

Security/Providers/No Security.cshtml

During authentication, the provider assigns the default security group defined in the configuration and initializes the session without validating user credentials. No username is required for access to report resources.

The No Security provider is typically used in development environments or scenarios where access to the report server is already controlled externally.

OpenId Provider

The OpenId provider authenticates users based on an OpenID token received through the request context and extracts identity information from the token payload.

Its implementation is located in the following script:

Security/Providers/OpenId.cshtml

During authentication, the provider reads the token payload and verifies the expiration timestamp before allowing access to report resources. If the token is valid, a security group is assigned to the active session based on information contained in the token claims. If no token is present, an alternate credential-based authentication flow may be used depending on provider configuration.

The OpenId provider is typically used when Seal Report Server is integrated with external identity providers supporting OpenID-based authentication workflows.

Authentication Providers Comparison Summary

The following table summarizes the main characteristics of the available authentication providers and helps identify which one best fits a particular deployment scenario.

Provider	Credentials Source	Infrastructure Requirement	Security Groups Resolution	Typical Usage Scenario
Basic Authentication	Security.xml (`<Logins>`)	None	From Security.xml	Local users stored inside Seal repository
Basic Windows Authentication	Windows account (manual login)	Windows domain or local machine accounts	Default group or mapped Windows groups	Windows credentials entered through login screen
Integrated Windows Authentication	IIS Windows identity	IIS Windows Authentication enabled	Default group or mapped Windows groups	Transparent domain authentication inside intranet
Claims Principal	HTTP request claims	External identity platform (e.g., Azure App Service)	Role-to-group matching	Reverse proxy / platform-managed authentication
Database Authentication	Database connection validation	Accessible relational database (OLE DB)	Default group or database-driven logic	Credentials stored in application database
LDAP Authentication	LDAP bind operation	LDAP / Active Directory server	Default group or LDAP-driven logic	Centralized directory authentication
JWT	Token payload	External token issuer	Group from token claim	API gateway / SSO / token-based authentication
OpenId	ID token payload	OpenID-compatible identity provider	Group from token claim	Cloud identity providers (OIDC workflows)
No Security	None	None	Default group only	Development or externally protected environments

The choice of authentication provider depends primarily on where user identities are managed and whether authentication should be handled directly by Seal Report Server or delegated to external infrastructure components such as IIS, directory services, databases, or token-based identity providers.

Report Execution Flow

To integrate Seal Report Server as an embedded component within a web application, the first request must call the {SealReportURI}/SWILogin endpoint with the expected payload and/or headers, depending on the authentication provider configured in the Seal Report Server.

If authentication succeeds, the server returns information about the current user session in JSON format. For example:

{
    "name": "username_here,
    "group": "user_group_here",
    "culture": null,
    "language": "en",
    "folder": "\\relative_path_to_the_folder_on_the_server",
    "showfolders": true,
    "editconfiguration": false,
    "editprofile": true,
    "downloadupload": 0,
    "changepassword": false,
    "showresetpassword": false,
    "usertag": null,
    "onstartup": 0,
    "startupreport": null,
    "startupreportname": null,
    "report": "",
    "reportname": "",
    "executionmode": 0,
    "groupexecutionmode": 1,
    "sources": [
        // data sources
        // and connections here
    ],
    "sessionId": "an_UUID_here"
}

The returned sessionId value must be included in all subsequent requests to the Seal Report Server.

After authentication is completed, reports can be executed by calling the {SealReportURI}/SWExecuteReport endpoint. This endpoint returns the generated HTML page containing all required JavaScript and CSS resources necessary for rendering the report.

The request to the SWExecuteReport endpoint uses the application/x-www-form-urlencoded content type and typically includes the following parameters:

sessionId
path (for example: /RelativePathToReports/ReportName.srex)

When embedding Seal Report Server into a custom web application, it is often necessary to introduce a client-side interceptor or script-loading mechanism to ensure that dynamically returned JavaScript resources are executed correctly and that additional business-driven UI customizations can be applied.

Remarks

Seal Report Server supports multiple authentication providers that can be selected depending on where user identities are managed: locally in Security.xml, within Windows infrastructure, directory services such as LDAP, databases, or external identity platforms using claims or tokens.

The authentication process starts with the {SealReportURI}/SWILogin endpoint and produces a session identifier required for all subsequent report execution requests.

Because authentication providers are script-based, they can be extended or adapted to match project-specific integration requirements without modifying the Seal Report Server core.

Getting Started With Seal Reports: Sharing Filters Across Multiple Models

Vlad Ganușceac — Mon, 13 Apr 2026 16:31:43 +0000

This is the seventh post in the series.

The final report may contain multiple UI elements: data tables, KPI widgets, and various types of charts. When several visual components and filters are applied, we typically assume that these filters operate globally across all underlying models.

In this post, I will use the HumanResources.vEmployee view from the AdventureWorks2025 database to demonstrate how filters can be shared across different UI components through a common model.

Defining Models

This example is intentionally simplified. All four models use only the HumanResources.vEmployee view. The naming of these models is deliberately explicit (“screaming”) to clearly reflect their purpose:

. Models
|__ 0.Shareable
|__ 1.DataTable
|__ 2.EmployeeJobTitlesChart
|__ 3.EmployeeProvincesChart

The common restrictions are defined within the 0.Shareable model, in the section with the same name:

[JobTitle Contains ?]
AND [FirstName Contains ?]
AND [MiddleName Contains ?]
AND [LastName Contains ?]
AND [EmailAddress Contains ?]
AND [PhoneNumber Contains ?]
AND [PhoneNumberType Contains ?]
AND [PostalCode Contains ?]
AND [City Contains ?]
AND [StateProvinceName Contains ?]
AND [CountryRegionName Contains ?]

For the remaining models, the 0.Shareable model must be referenced in the Reference model option within the Model definition section. This allows all UI components to reuse the same filtering logic consistently across the report.

For the 1.DataTable model, the following properties are placed within the Row Elements section:

JobTitle
FirstName
MiddleName
LastName
EmailAddress
PhoneNumber
PhoneNumberType
PostalCode
City
StateProvinceName
CountryRegionName

For the 2.EmployeeJobTitlesChart model, the JobTitle property is placed in the Row Elements section as the axis series definition. The BusinessEntityID property is placed in the Data Elements section as an NVD3 Pie series using the Count Distinct aggregate.

For the 3.EmployeeProvincesChart model, the StateProvinceName property is placed in the Row Elements section. The BusinessEntityID property is used in the Data Elements section with a Count Distinct aggregation as an NVD3 Bar series.

The chart configurations themselves are not the focus here; they simply demonstrate how multiple visual components can reuse a shared filtering model.

Visualizing Multiple Models

In the previous posts, we worked with a single model. Now, let’s see how multiple models can be used together within the same report.

In this example, the data table is displayed inside a bottom container, while the top container includes two charts: Employees' Provinces and Top 10 Job Titles.

The following hierarchy is configured within the Views folder:

. View
|__ Widget --Widget view
   |__ 2.EmployeeJobTitlesChart --Model view
      |__ Container --Container view
         |__ Chart NVD3 --Chart NVD3 view
   |__ 3.EmployeeProvincesChart --Model view
      |__ Container --Container view
         |__ Chart NVD3 --Chart NVD3 view
|__ Widget --Widget view
   |__ 1.DataTable --Container view
      |__ DataTable --Data table view

At this point, each visualization is powered by its own model, but all of them inherit the same filtering logic from the shared model defined earlier.

Getting Started With Seal Report: Mapping Restrictions to SQL User-Defined Functions

Vlad Ganușceac — Sun, 05 Apr 2026 12:28:58 +0000

This is the sixth post in the series.

It is quite common that restrictions applied at the data model property level (regardless of their origin—expression filters, static or dynamic enumerations, etc.) cannot implement the complex business logic that a stored procedure or a user-defined function can handle.

Another motivation is related to custom joins defined in the generated SQL statement. In such cases, it is not always optimal to rely on JOIN statements generated automatically (under the hood) instead of using EXISTS statements that a database administrator might prefer for performance or clarity reasons.

The goal of this post is to demonstrate how to map data model restrictions to the parameters of a user-defined function (UDF) or stored procedure.

Defining a "Virtual" Table

This exercise mostly mimics what was described in the previous post:

Vlad Ganușceac

Apr 2

Getting Started With Seal Report: Applying Custom Joins

#sealreport #analytics #sql #tutorial

Comments

4 min read

The custom (non-base) table in this post will use the following user-defined function (UDF):

CREATE OR ALTER FUNCTION dbo.udf_get_persons
(
    @state_province_ids NVARCHAR(MAX) = NULL,
    @department_ids NVARCHAR(MAX) = NULL
)
RETURNS TABLE
AS
RETURN
(
    SELECT 
        person.FirstName,
        person.MiddleName,
        person.LastName,
        employee.BirthDate,
        employee.Gender,
        employee.MaritalStatus,
        employee.JobTitle
    FROM Person.Person person
    INNER JOIN HumanResources.Employee employee
        ON person.BusinessEntityID = employee.BusinessEntityID
    WHERE
        (
            NULLIF(NULLIF(@state_province_ids,''),'NULL') IS NULL
            OR EXISTS
            (
                SELECT 1
                FROM Person.BusinessEntityAddress entity_address
                JOIN Person.Address address
                    ON address.AddressID = entity_address.AddressID
                WHERE entity_address.BusinessEntityID = person.BusinessEntityID
                AND address.StateProvinceID IN
                (
                    SELECT TRY_CAST(value AS INT)
                    FROM STRING_SPLIT(
                        REPLACE(REPLACE(@state_province_ids,'(',''),')',''),
                        ','
                    )
                )
            )
        )
        AND
        (
            NULLIF(NULLIF(@department_ids,''),'NULL') IS NULL
            OR EXISTS
            (
                SELECT 1
                FROM HumanResources.EmployeeDepartmentHistory edh
                WHERE edh.BusinessEntityID = employee.BusinessEntityID
                AND edh.EndDate IS NULL
                AND edh.DepartmentID IN
                (
                    SELECT TRY_CAST(value AS INT)
                    FROM STRING_SPLIT(
                        REPLACE(REPLACE(@department_ids,'(',''),')',''),
                        ','
                    )
                )
            )
        )
)

The user-defined function is already adapted to Seal Report conventions: it accepts multiple selected values as parameters, or NULL if nothing is selected.

The SQL above demonstrates an example that Seal Report would not generate automatically. The motivation is straightforward: if no properties from the joined table need to be selected, why use a JOIN statement instead of an EXISTS condition?

The main difference is that the UDF shown above should be invoked like this:

SELECT *
FROM dbo.udf_get_persons(
    '{CommonRestriction_ProvinceIds}',
    '{CommonRestriction_DepartmentIds}'
)

If you receive errors when using the Refresh columns (F9) and Check SQL options, don’t worry — here is the workaround:

Temporarily use default values as parameters in order to generate the required table columns:
SELECT * 
FROM dbo.udf_get_persons(
    NULL, 
    NULL
)

Applying the UDF to the Data Model

The next step is to define Common restrictions and values within the data model. However, these will not appear unless at least one property from the virtual table is added to the Elements section.

So, let’s drag and drop all the properties available in our virtual table into the Row Elements section.

Once the virtual table exists and its properties are mapped to the data model, it becomes possible to map the UDF input parameters to the model restrictions.

Next, navigate to Models → Model → Model Definition → Common restrictions and values to configure the restrictions.

The two UDF restrictions should already be available for configuration.

These common restrictions should be linked to dynamic select lists by design.

I previously covered how to configure dynamic select lists here:

Vlad Ganușceac

Mar 26

Getting Started with Seal Report: Static and Dynamic Select Lists

#sealreport #tutorial #analytics #sqlserver

Comments

4 min read

Skill Check

If you didn’t identify the required configuration for the common restrictions, here is my version:

The final result should look like this:

When using an MSSQL stored procedure, what limitation prevents you from implementing the same approach as with a UDF?

To better understand the behavior, try applying different filters. You may encounter issues when using multi-select values of type Text. In such cases, consider using a single value per parameter instead.

This example demonstrates several edge-case scenarios that are very useful in real-life reporting situations

In the next post, I will demonstrate how to create shared filters across multiple UI elements.

Getting Started With Seal Report: Applying Custom Joins

Vlad Ganușceac — Thu, 02 Apr 2026 17:22:45 +0000

This is the fifth post in the series.

Retrieving data automatically from multiple tables is powerful. However, in many real-world reporting scenarios, dashboards and analytical reports rely on custom SQL expressions, user-defined functions, or stored procedures.

In this post, I’ll show how to link SQL expressions with other tables so you can benefit from both approaches at the same time - keeping Seal Report’s automatic joins and filters while still using custom SQL logic.

As a prerequisite, you should have an instance of the AdventureWorks2025 database available and be familiar with configuring a data source connection in Seal Report.

Previously, we've covered up how to apply dependent filters:

Vlad Ganușceac

Mar 29

Getting Started with Seal Report: Applying Dependant Filters

#sealreport #sql #analytics #tutorial

Comments

3 min read

The Goal

In this post, we will rewrite the report created in the previous article using a different approach:

retrieving data from the Person.Person table together with data from the HumanResources schema using a single SQL expression;
applying a custom join between this SQL expression and the Person.Person table;
keeping the rest of the dynamic and custom filters available, just like in the previous posts in this series.

The SQL statement used in this example will not be implemented as a parameterized user-defined function or stored procedure, as that scenario will be covered in the next article:

SELECT 
    employee.BusinessEntityID
    , employee.JobTitle
    , employee.BirthDate
    , employee.MaritalStatus
    , employee.Gender
    , person.FirstName
    , person.MiddleName
    , person.LastName
    , pay_history.PayFrequency
    , pay_history.Rate
FROM HumanResources.Employee employee
    LEFT JOIN HumanResources.EmployeePayHistory pay_history
        on employee.BusinessEntityID = pay_history.BusinessEntityID
    INNER JOIN Person.Person person
        on employee.BusinessEntityID = person.BusinessEntityID

Joining Data Tables Within the Data Source

To add the SQL expression as a virtual table, open Sources → Data Source → Tables and choose Add Table.

In the configuration panel on the right side, set the Name property to Employees_Virtual, then paste the SQL query into SQL Select Statement.

After that, press F9 (or Refresh columns) so that Seal Report loads the column definitions from the query.

At this point, the SQL expression becomes available as a regular table inside the data source and can be used later when defining joins.

Note that this does not create a new table in the database — the table exists only at the data source level in Seal Report.

The following data tables should be loaded from the Catalog:

Person.Person
Person.BusinessEntity
Person.BusinessEntityAddress
Person.Address
Person.StateProvince
Person.CountryRegion

After loading them, the Tables section should look like this:

Now it is time to apply a custom join statement. Open Sources → Data Source → Joins and use the Add Join option from the context menu.

Since the required join is bi-directional, it does not matter whether the virtual table is defined as the left or the right side of the join. In the Join clause, apply the following condition:

Employee_Virtual.BusinessEntityID = Person.Person.BusinessEntityID

The joins used in this example are shown in the screenshot below:

Creating Pivot Table and Using Custom Filters

This time, the elements used for data visualization will be retrieved from a single source — the Employee_Virtual custom table.

The Row Elements should contain the following properties:

FirstName
MiddleName
LastName
JobTitle
BirthDate
MaritalStatus
Gender

For the pivoted part, the Column Elements should contain PayFrequency, and the Data Elements should contain the Rate property.

Let’s apply the what-I-see-is-what-I-can-filter principle to the static part of the table definition. Drag and drop the same properties used within the Row Elements into the Restriction section. Do not forget to enable prompt restrictions for the newly added expressions in that section.

If everything has been configured correctly, the model definition should look like this:

If you had any difficulties completing this exercise, you may take a look at the following post:

Vlad Ganușceac

Mar 22

Getting Started with Seal Report: Creating a Pivot Table with Custom Filters

#sealreport #tutorial #sqlserver #analytics

Comments

3 min read

Skill Check

Only one step remains to reach the final goal — applying a filter on a table other than the custom one and verifying that it influences the report output.

Since we defined a custom join between the Employee_Virtual table and the base table (Person.Person), we now need to apply a restriction within the Person schema to complete the scenario.

Let’s drag and drop the CountryRegionCode field from Person.CountryRegion into the Restrictions section.

For example, applying the FR region code will return just one row in the table:

The example above would be even more useful if dependent filters were applied to CountryRegion and StateProvince. Try implementing them yourself. If you encounter any difficulties, the previous post explains how to configure them.

So far, so good. In the next post, I will show how to pass parameters into user-defined functions and stored procedures when using them as data sources in Seal Report.

Getting Started with Seal Report: Applying Dependant Filters

Vlad Ganușceac — Sun, 29 Mar 2026 11:18:19 +0000

This is the fourth report in the series.

So far, we’ve used different types of restrictions, but those were independent of each other. However, real-world filtering scenarios often require dependent restrictions, where one selection affects the available values of another.

Within the AdventureWorks2025 open-source database, there is a classic example of such dependency: CountryRegion → StateProvince.

Applying this type of filter allows us to narrow down employees based on the province associated with one of their recorded addresses, while ensuring that only provinces belonging to the selected country are available for selection.

In the previous post, we examined static and dynamic select lists as data table restrictions.

Vlad Ganușceac

Mar 26

Getting Started with Seal Report: Static and Dynamic Select Lists

#sealreport #tutorial #analytics #sqlserver

Comments

4 min read

In this article, we will configure dependent select lists so that the available StateProvince values automatically adjust based on the selected CountryRegion.

Adding Necessary Data Tables from the Catalog

To accomplish the desired task, several data tables must first be imported from the Catalog. The process was described in the first article of this series:

Vlad Ganușceac

Mar 21

Getting Started with Seal Report: Building Your First Data Table from SQL Server

#sealreport #opensource #analytics #sqlserver

Comments

4 min read

For the current scenario, the following data tables need to be imported from the AdventureWorks2025 database:

Person.CountryRegion,
Person.StateProvince,
Person.Address,
Person.BusinessEntityAddress,
Person.BusinessEntity.

These tables allow us to build the relationship chain required to filter employees by the province associated with their addresses, while ensuring that the selected province belongs to the chosen country.

If the Auto create joins option was enabled during import, the records in the Joins section should look similar to the following:

Adding the Main Enumeration

The process is straightforward. Add a dynamic enumeration using the following SQL Select Statement:

SELECT
    CountryRegionCode AS [KEY],
    Name AS [VALUE]
FROM Person.CountryRegion
ORDER BY Name

Because the values are retrieved from the query, the enumeration must be configured to load its content dynamically from the SQL Select Statement and refreshed before report execution.

I've named this enumeration as CountryRegion. This enumeration name will be referenced later when configuring the dependent select list.

Next, open Models → Model and drag the CountryRegionCode property from the Person.CountryRegion data table into the Restrictions section.

The newly created restriction can now be linked to the CountryRegion enumeration by selecting it as the custom enumerated list from the Advanced configuration panel.

Finally, enable Prompt at execution so the restriction becomes available when running the report.

Adding the Dependant Enumeration

Things become slightly more interesting when configuring the dependent enumeration.

At first glance, its main configuration looks similar to the previous example. The base SQL Select Statement still loads all available values and does not reference any restrictions:

SELECT
    StateProvinceID as [KEY],
    Name as [Value]
FROM Person.StateProvince
ORDER BY Name

The dependency itself is defined separately, inside Dynamic display → SQL Select Statement for prompted restriction:

SELECT
    StateProvinceID as [Key],
    Name as [Value]
FROM Person.StateProvince
WHERE CountryRegionCode IN ({EnumValues_CountryRegion})
ORDER BY Name

The dependency is implemented inside the SQL Select Statement for prompted restriction, where the selected values of the CountryRegion restriction are referenced using the {EnumValues_CountryRegion} pattern. This ensures that only the provinces belonging to the selected country remain available in the StateProvince enumeration.

The restriction itself is then added to the report in the same way as in the previous examples, so no additional configuration is required at the model level.

Skill Check

If everything has been configured as described in this post:

initially, the StateProvince filter remains empty because no country or region has yet been selected in the CountryRegion filter:

after selecting a region such as United Kingdom, the dependent filter is refreshed automatically and displays only the corresponding provinces:

As an additional exercise, try making the dependent filter required and configure a display message indicating that a country or region must be selected first.

So far, all examples in this series have been based on data tables as the underlying data source. However, real-life reporting scenarios often rely on stored procedures and user-defined functions. In the next post, we’ll explore how the same filtering techniques can be applied when working with those types of sources.

Getting Started with Seal Report: Static and Dynamic Select Lists

Vlad Ganușceac — Thu, 26 Mar 2026 22:33:48 +0000

This is the third post in the series.

In the previous post, we created a pivot table with custom filters. While those filters allowed us to apply constraints such as Equals, Contains, and Between, it would be useful to extend the example further by introducing static and dynamic select lists as filtering options.

In this post, we will enhance the existing solution by integrating these select lists and exploring how they improve the filtering experience.

Below is the link to the previous post:

Vlad Ganușceac

Mar 22

Getting Started with Seal Report: Creating a Pivot Table with Custom Filters

#sealreport #tutorial #sqlserver #analytics

Comments

3 min read

Adding a Static Enumeration

In the context of Seal Report, a static enumeration is a collection of key-value pairs defined directly in the report’s XML document definition.

For example, instead of retrieving the distinct values of PayFrequency from the HumanResources.EmployeePayHistory table, it is often more efficient to store these values directly in the data model used for rendering the report. Even executing a hardcoded SQL query each time the report runs would be less efficient than using a predefined collection.

In this case, the static enumeration behaves like a constant list that is already available at runtime and does not require additional database queries.

Select the Add Enum option available under Sources → Data Source → Enumerated Lists. A contextual configuration panel will appear on the right side.

Within the enum definition, provide a meaningful Name, and configure the following options if needed:

whether the list is dynamically loaded from a SQL Select Statement or from a Load Script
whether the list should be refreshed before report execution
whether the list values depend on the connection.

These settings allow you to control how enumeration values are loaded and updated during report execution.

For the current scope, all these options remain set to False, since we are defining a static enumeration.

The SQL Select Statement used to define the enumeration values is the following:

SELECT *
FROM (VALUES
    (1, 'Monthly'),
    (2, 'Biweekly')
) AS PayFrequencyEnum([Key], [Value])

The enum's configuration looks this way:

Note that the Refresh values option may not appear immediately in the UI. If it is not visible, reopen the enum definition or temporarily enable a dynamic loading option so the two values become available in the final collection.

The enumeration created in the UI is persisted in the report definition as a <MetaEnum> element. A simplified example looks like this:

<MetaEnum>
  <GUID>a90b0ce6-bde8-4199-8869-f2ce0c1218ce</GUID>
  <Name>PayrollFrequency</Name>
  <Sql>SELECT *
FROM (VALUES
    (CAST(1 AS INT), 'Monthly'),
    (CAST(2 AS INT), 'Biweekly')
) AS PayFrequencyEnum([Key], [Value])</Sql>
  <Values>
    <MetaEV>
      <Id>1</Id>
      <Val>Monthly</Val>
    </MetaEV>
    <MetaEV>
      <Id>2</Id>
      <Val>Biweekly</Val>
    </MetaEV>
  </Values>
</MetaEnum>

If the enumeration is configured as static, the actual values used at runtime are stored inside the <Values> section. In this case, the <Sql> element is not required for execution and mainly serves as a definition template.

You can even remove the <Sql> element and keep only the <Values> collection to preserve the same static behavior.

Adding a Dynamic Enumeration

For a dynamic enumeration, let’s select a set of properties directly from the database that are expected to change over time.

For example, the HumanResources.EmployeeDepartmentHistory table references the HumanResources.Shift table. This means that the available shift values may change in the future as new shifts are added or existing ones are modified.

In such scenarios, using a dynamic enumeration ensures that the list of available values is always loaded from the database and reflects the current state of the data.

For this particular case, the list will be dynamically loaded from the SQL Select Statement, and its values will depend on the connection.

I've chosen the following SQL Select Statement:

SELECT 
    [ShiftID] AS [KEY],
    CONCAT(
        [Name], 
        ' (',
        FORMAT(CAST([StartTime] AS datetime2), 'HH:mm'),
        ' - ',
        FORMAT(CAST([EndTime] AS datetime2), 'HH:mm'),
        ')'
    ) AS [VALUE]
FROM [AdventureWorks2025].[HumanResources].[Shift]

The configuration looks the following way:

The enumeration will be reflected in the report definition like this:

<MetaEnum>
            <GUID>c107bf33-5f3a-4f26-908d-48a8f768d0d9</GUID>
            <Name>Shifts</Name>
            <IsDynamic>true</IsDynamic>
            <ValuesPerConnection>true</ValuesPerConnection>
            <Sql>SELECT 
    [ShiftID] AS [KEY],
    CONCAT(
        [Name], 
        ' (',
        FORMAT(CAST([StartTime] AS datetime2), 'HH:mm'),
        ' - ',
        FORMAT(CAST([EndTime] AS datetime2), 'HH:mm'),
        ')'
    ) AS [VALUE]
FROM [AdventureWorks2025].[HumanResources].[Shift]</Sql>
          </MetaEnum>

Note that the report definition may also include a key–value collection inside a <Values> section. This typically appears after selecting Refresh values or pressing F9, which materializes the current enumeration entries in the report model.

Applying Enumerations on Restrictions

The process of applying a select-based filter is very similar to the one used for expression-based filters. The key difference is that, within the Advanced section, you must select the appropriate Custom enum.

Drag and drop the PayFrequency property from the HumanResources.EmployeePayHistory table into the Restrictions section. Then click on the newly created [PayFrequency Equals] expression. In the contextual panel on the right side, navigate to the Advanced section and select the PayrollFrequency enumeration.

Execute the report, and you will see the available filters as shown in the screenshot below.

It does not matter whether the enumeration is static or dynamic — both are applied in the same way when configuring a restriction or filter.

Skill Check

Apply the Shifts enumeration to the ShiftID property from the HumanResources.Shift table. The process is similar to the one discussed in the previous section.

Hint: combine restrictions using both the PayrollFrequency and Shifts enumerations.

If you’ve configured it successfully, try answering the following questions:

How many employees from the Engineering department have agreed to a Biweekly payroll frequency and are working the Day shift (07:00 – 15:00)?
How many employees with a FirstName starting with Chris are assigned to either the Evening or Night shift?

Dependent select lists allow one enumeration to react dynamically to the selection of another. In one of the following posts, I will show you how to apply dependent select lists.

Quick Summary

Static vs Dynamic Enumerations

Feature	Static	Dynamic
Loaded at runtime	❌ No	✅ Yes
Requires SQL execution	❌ No	✅ Yes
Stored in `<Values>`	✅ Yes	Optional
Reflects DB changes automatically	❌ No	✅ Yes
Depends on connection	❌ No	Optional

Use static enumerations for constant lookup lists and dynamic enumerations when values must reflect the current database state.

Getting Started with Seal Report: Creating a Pivot Table with Custom Filters

Vlad Ganușceac — Sun, 22 Mar 2026 12:28:42 +0000

This is the second post in the series.

In this article, I assume that you’re already familiar with how to configure a data source in Seal Report and how to set up metadata model elements from a table loaded via the catalog.

You can find the previous post here:

Vlad Ganușceac

Mar 21

Getting Started with Seal Report: Building Your First Data Table from SQL Server

#sealreport #opensource #analytics #sqlserver

Comments

4 min read

The previous report used only out-of-the-box features. In this tutorial, we will extend it by adding a pivot table and introducing custom filters.

Adding a Pivot Table

Since the current report visualizes data from the HumanResources.Employee and Person.Person tables of the AdventureWorks2025 database, we need to use a one-to-many relationship with one of these tables to provide data suitable for a pivot table.

Let’s drag the Rate property from HumanResources.EmployeePayHistory into the Drop Data Elements section of the metadata model. Then drag the PayFrequency property from the same table into the Drop Column Elements section.

The final configuration will look like this:

Click the Execute button to see the result.

Now, in addition to the static columns, a list of payment rates grouped by frequency will appear.

Note that when you click the Rate property inside the Drop Data Elements section, a context panel appears on the right side. There you can configure several important data options:

Aggregate (default: Sum)
Calculation option (disabled by default)
Show total (disabled by default)

These settings control how numeric values are calculated and displayed in the pivot output.

Adding Custom Filters

Besides the default multi-column search available in the data table view, it is useful to add the ability to filter data using different expressions per column.

In this context, filters refer to the Restrictions and Aggregate Restrictions section located at the bottom of the Models → Model configuration panel.

These restrictions allow you to define parameterized filters that can be reused across report views and applied before the data is rendered.

Let’s drag and drop into the Restrictions and Aggregate Restrictions section the same properties that were previously added to the Row Elements of the metadata model.

For each restriction, enable the Prompt at execution option in the Prompt restriction setting so that users can specify filter values when running the report.

Your configuration should look like this:

Click the Execute button. In the new window, the newly added filters will appear. These filters are optional.

Click Execute again in that window to run the report.

Try applying different combinations of filters. The results displayed in the data table will change depending on the selected filter values.

Skill Check

So far, we have followed the approach "you filter what you see", meaning that restrictions were added only for the fields already present in the report model.

Try adding the Name field from HumanResources.Department table as Department restriction with default value set to Engineering.

Some readers might wonder why we are not using select lists yet, especially since SQL-based lists better represent real-life filtering scenarios than simple column-based restrictions.

In the next article, we will configure dynamic SQL-based select-list filters, making restrictions more flexible and closer to real-world reporting scenarios.

Getting Started with Seal Report: Building Your First Data Table from SQL Server

Vlad Ganușceac — Sat, 21 Mar 2026 17:54:42 +0000

The first time I was assigned a task to create a Seal Report for data visualization, I quickly discovered there were very few posts, articles, or practical tutorials explaining how to accomplish common tasks. The official .srex XML-based report definitions are available inside the Seal Report Designer, but in many cases the experience still feels like "figure it out on your own".

Seal Report is an open-source reporting framework for .NET that allows building dynamic reports from SQL data sources with minimal configuration.

The motivation behind this post is to provide a starting point for developers who are struggling to find clear guidance on how to work efficiently with Seal Report.

In this short tutorial, I will use the AdventureWorks2025 open-source backup database. Make sure the database is restored in your SQL Server instance before starting the tutorial.

All examples described below are executed using Seal Report Designer (Community Edition).

This tutorial focuses on building a simple working report from scratch using Seal Report Designer and is intended as a starting point for developers who are new to the tool.

Configuring Data Source

Below are the steps required to configure a data source that will later be used for data visualization:

Open Seal Report Designer
Click the New icon
In the left panel, right-click the Sources folder
Select Add a new SQL Data Source

After completing these steps, a dummy SQL data source will be created.

For simplicity, you can delete the default data sources and repositories created automatically by Seal Report, since they are not required for this tutorial. Keeping only the necessary elements makes the configuration easier to follow and avoids confusion later.

At this point, your workspace should look similar to the screenshot below.

To connect the data source to an existing database, navigate to: Sources → Data Source → Connections → connection.

After selecting connection, the contextual configuration panel becomes available on the right side.

For this tutorial, use the following settings:

Database type: MS SQLServer
Connection type: MS SQLServer (System.Data)
Connection string:

Data Source=localhost\SQLEXPRESS;
Initial Catalog=AdventureWorks2025;
Integrated Security=True;
TrustServerCertificate=True;

Once the connection string is configured, press F7 or click Check connection to verify that the connection is working correctly.

If everything is configured properly, the result should match the confirmation shown in the screenshot below.

Loading Tables and Views from the Catalog

After the database connection is established, tables and views can be loaded from the database catalog for further use in the report model.

Open Sources → Data Source → Tables, then right-click Tables and select Add Tables from Catalog.

In the popup window, enter HumanResources in the filter field and click Select all. Enable the following mapping options:

Auto create joins
Auto create table columns
Use schema name
Keep column names

These options automatically prepare the selected tables for reporting by generating joins between them and creating the required column metadata.

The result should look similar to the screenshot below.

Configuring the Metadata Model

Inside the Models folder, there is already a metadata Model element created by default. Select it and, in the contextual panel on the right side, set the following values:

Source → Data Source
Connection → connection

At the bottom of the same contextual panel, you will see the list of tables imported earlier from the catalog. Expand the HumanResources.Employee table and drag the following fields into the Drop Row Element area:

BusinessEntityID
JobTitle
BirthDate
MaritalStatus
Gender

At this stage, before previewing the result, your configuration should look similar to the screenshot below.

By clicking the Execute button, the data is loaded from the database, mapped to the metadata model, and rendered in the UI using the Razor engine.

As you can see, by default:

all columns are sortable
pagination is enabled
a global table filter is available
the maximum number of records per page can be adjusted

These features are available out of the box and do not require any additional configuration.

Skill Check

You may notice that displaying BusinessEntityID instead of a person’s full name looks awkward. As a small exercise, try adding the Person.Person table from the catalog and replacing the identifier with the FirstName, MiddleName, and LastName fields.

If everything is configured correctly, the resulting data table should look like this:

In the next post, I will show how to apply custom filters and how to build a pivot table.

DEV Community: Vlad Ganușceac

Overview: Getting Started with Seal Report

Remarks

Getting Started with Seal Report: Authentication Providers

Inspecting the Security.xml File

Basic Authentication Provider

Basic Windows Authentication Provider

Claims Principal Provider

Database Authentication Provider

Integrated Windows Authentication Provider

JWT Provider

LDAP Authentication Provider

No Security Provider

OpenId Provider

Authentication Providers Comparison Summary

Report Execution Flow

Remarks

Getting Started With Seal Reports: Sharing Filters Across Multiple Models

Defining Models

Visualizing Multiple Models

Getting Started With Seal Report: Mapping Restrictions to SQL User-Defined Functions

Defining a "Virtual" Table

Applying the UDF to the Data Model

Skill Check

Getting Started With Seal Report: Applying Custom Joins

The Goal

Joining Data Tables Within the Data Source

Creating Pivot Table and Using Custom Filters

Skill Check

Getting Started with Seal Report: Applying Dependant Filters

Adding Necessary Data Tables from the Catalog

Adding the Main Enumeration

Adding the Dependant Enumeration

Skill Check

Getting Started with Seal Report: Static and Dynamic Select Lists

Adding a Static Enumeration

Adding a Dynamic Enumeration

Applying Enumerations on Restrictions

Skill Check

Quick Summary

Static vs Dynamic Enumerations

Getting Started with Seal Report: Creating a Pivot Table with Custom Filters

Adding a Pivot Table

Adding Custom Filters

Skill Check

Getting Started with Seal Report: Building Your First Data Table from SQL Server

Configuring Data Source

Loading Tables and Views from the Catalog

Configuring the Metadata Model

Skill Check

Inspecting the `Security.xml` File