Table of Contents

Providing data

This page explains how to supply data to List & Label Cross Platform for report generation.

Understanding data binding in LLCP

LLCP uses a data provider model to abstract data sources. This architecture allows reports to work with different data backends (SQL databases, JSON, CSV, in-memory collections) without changing the report template.

The IDataProvider architecture

At its core, LLCP represents data using the IDataProvider interface, which exposes:

  • ITable - represents a data table with rows and columns
  • ITableRelation - defines relationships between tables

This mimics a relational database structure, making it familiar to developers and flexible enough to adapt to various data sources.

Developers can implement their own IDataProvider or use one of the many preconfigured providers available in the combit.Reporting.DataProviders namespace.

Why this design?

Separation of concerns
Reports define what to display; data providers define where data comes from. You can switch data sources without modifying report templates.

Flexibility
The same report template can work with SQL databases, JSON APIs, CSV files, or in-memory objects by simply changing the data provider.

Testability
You can use lightweight in-memory data providers for testing without requiring database access.

When to use which data provider

Use case Recommended provider Reason
SQL Server database SqlConnectionDataProvider Native ADO.NET integration, efficient for large datasets
Oracle database OracleConnectionDataProvider Optimized for Oracle-specific features
MySQL database MySqlConnectionDataProvider MySQL Connector/NET support
REST API or web service JsonDataProvider Parses JSON responses directly
CSV files or exports CsvDataProvider Simple, file-based data source
In-memory collections InMemoryDataProvider Testing, computed data, or small datasets
Azure SQL AzureSqlDataProvider Cloud-optimized authentication and connection handling
Tip

If you have an existing ADO.NET connection or DataSet, the corresponding data provider typically requires minimal integration effort.

Data provider packages

To keep dependencies minimal, most data providers are distributed as separate NuGet packages. You can find available packages on NuGet.

The package name typically matches the data provider class name. Refer to the assembly name in the documentation of each data provider to identify which package you need.

Binding data using SqlConnectionDataProvider

One common scenario is connecting to a SQL Server database. The SqlConnectionDataProvider is a preconfigured provider that leverages ADO.NET to establish this connection. Below is an example snippet that demonstrates how to bind a SQL database to List & Label:

using combit.Reporting.DataProviders;
using System.Data.SqlClient;

// Define your SQL connection string
string connectionString = "your SQL connection string here";

// Establish a SQL connection
using SqlConnection connection = new SqlConnection(connectionString);

// Create a SQL connection data provider and enable automatic connection closing
var sqlProvider = new SqlConnectionDataProvider(connection);

// Bind the data provider to List & Label
listLabel.DataSource = sqlProvider;
Note

Replace "your SQL connection string here" with your actual connection string. This snippet demonstrates a straightforward way to integrate SQL Server data into your reporting projects.

Top 10 data providers

Below is a table listing the ten most important data providers, chosen based on their relevance for common data formats and relational databases:

Provider name Description
SqlConnectionDataProvider Provides data access capabilities for SQL Server connections.
OracleConnectionDataProvider Implements data provider functionality for Oracle databases using ADO.NET.
MySqlConnectionDataProvider Enables connectivity to MySQL databases via the MySQL Connector/NET.
SQLiteConnectionDataProvider Offers a lightweight provider for SQLite connections, tested with version 1.0.92.0.
AzureSqlDataProvider Connects to Azure SQL databases using an AzureSqlDataProviderConfiguration for cloud scenarios.
AccessDataProvider Provides a data provider implementation for Microsoft Access databases.
CsvDataProvider Extracts data from CSV files, enabling easy integration of comma-separated data sources.
JsonDataProvider Supports data retrieval from JSON data streams, ideal for web APIs and file-based JSON data.
InMemoryDataProvider Wraps existing ITable instances into an in-memory data provider, allowing dynamic data manipulation.
OdbcConnectionDataProvider Offers a generic provider for databases accessible via ODBC connections, ensuring broad compatibility.
Tip

All these providers are available in the combit.Reporting.DataProviders namespace. Depending on your application's requirements, you may choose to implement a custom IDataProvider or leverage these preconfigured solutions.

By using these data providers, you can easily integrate various data sources into your List & Label projects, enabling dynamic report generation across diverse environments.

Performance and scalability considerations

When working with data providers in production:

Connection management

  • Use connection pooling for database providers (enabled by default in ADO.NET)
  • Dispose data provider instances properly to release resources
  • Consider connection lifetime in containerized or serverless environments

Data volume

  • Database providers stream results efficiently for large datasets
  • JSON and CSV providers load entire files into memory—consider file size limits
  • For very large reports, test memory usage and rendering time with representative data

Parallel report generation

  • Most data providers are not thread-safe—create separate instances per thread or request
  • Database connection pools handle concurrent access automatically
  • In-memory providers require careful synchronization if shared across threads
Important

Always test with production-like data volumes and concurrency levels before deploying to production.

Troubleshooting data provider issues

Connection failures

Symptom: ListLabelException with database connection errors

Causes and solutions:

  • Invalid connection string: Verify connection string format and credentials
  • Network access: Ensure the application can reach the database server (firewall, VPN, security groups)
  • Authentication: Check that credentials are correct and the user has necessary permissions
  • Missing driver: Install required database client libraries or NuGet packages

Schema mismatches

Symptom: Fields missing from report or incorrect data types

Causes and solutions:

  • Report designed for different schema: Re-design report with current data provider schema
  • Case sensitivity: Check field name casing
  • Type conversions: Ensure data types match report field expectations (dates, numbers, strings)

Performance issues

Symptom: Slow report generation or high memory usage

Causes and solutions:

  • Missing indexes: Database queries may be inefficient—review query plans and add indexes
  • Large result sets: Limit data in queries or implement pagination
  • File size: JSON/CSV providers load files entirely—consider streaming or chunking
  • Connection overhead: Reuse connections or enable pooling
Tip

Enable logging (see Debugging and troubleshooting) to identify which operations are slow or failing.