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.
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.
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.
The data provider concept has been around for a couple of years now. We steadily work on extending the list of available data providers and can bind to most any data source by now. Besides the well-known ones, there are also some meta providers that deserve some spotlight.
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).