DEV Community: Vlad Ganușceac

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.