InMemoryDataProviderWrapper: Data Provider on Steroids

The features of different data providers vary widely. Depending on the data source, sorting, native aggregate functions or filters at database level may be available directly. Or not. For example, none of this is available in file-based formats such as JSON or XML, or even in “web” formats such as REST. These are typically read “front to back” and therefore cannot offer sorting or native aggregation. With List & Label 29, we have something new to offer.

New Data Provider for Azure Cosmos Database

Azure Cosmos DB is a fully managed Microsoft NoSQL database for modern app development, which is growing in popularity. Various APIs are available for connecting to Cosmos DB, as for example SQL API, Cassandra API or MongoDB API. Since we’re already able to connect to MongoDB or Cassandra through their own data providers, we’ll use the SQL API for the provider.

Introducing Parametrized Data Sources

List & Label's powerful filter options could not be used for all data sources so far. Reason is, especially for web based data sources, it is not possible or feasible to get "all" data first and then filter to the desired subset. The upcoming version 24 comes with a powerful new feature that addresses this very issue: Parametrized Data Sources. It allows to combine data source parameters with actual report parameters in the Designer.

Supporting Cross-Datasource Relations

The .NET DataProvider concept allows to bind to almost any data source. Basically, it mimics a relational database management system containing tables, relations, sort orders etc. However, often you'll find yourself needing to combine data from different sources, e.g. a server log file that contains customer logins and a SQL customer database that contains all pertinent information about the customers.

Huge Designer Speed-Up for Large Databases

Historically, List & Label has always been working without a database in the background. During the years, we've added powerful databinding to the components, however at the core, the principle stayed the same: your application (or the databinding layer) passes all available data before opening the Designer.

Filtering at Database Level

edit filter

Using report parameters has become very popular since we've introduced them in version 19. A typical use case that will become even more seminal with version 20 of our reporting tool is using parameters to filter data (see last feature focus). This is something we've usually put on the "don't" list as databases can filter data much faster than we can. In the past, all records had to be passed to the reporting engine which then decided if a record should be used or not. A vast overhead for a task databases are usually optimized for. In version 20, we'll be introducing a new feature that allows List & Label filter expressions to be translated to native database filters, therefore hugely increasing performance (in principle, depending on the data this is "infinitely" faster).