Defining Sub Tables via Filter Conditions

This is another great addition to the report container's feature set. Until LL25, related tables always needed to have an actual relation on the data source level in order to be usable as data source for sub items. If there was no relation, there was no way to insert the sub item, even if both tables in question had an ID field that would easily allow a custom linkage. In LL25, you can now have relations based on filter conditions.

A typical use case: think of an SQL database where the relations are not set on the server level (which happens more often than never) or two loosely related tables where the key might be a combination of a couple of fields. Or you have a mixed data source, e.g. a CSV file and an XML file that are coupled via an ID field. While for the latter case there has been a code based solution around for a while, this new feature lives entirely in the Designer. The performance heavily relies on filtering at database level – it is strongly suggested to use only database-translatable filters when using this new feature.

You can even define virtual relations, e.g. based on dates using this feature. Let’s do a quick walkthrough. For this sample, we’ll be using Microsoft’s Contoso sample database for SQL Server. Did you know the demo application is capable of binding to any SQL datasource? Just choose “Custom Data Sources” and find yourself in the well known realm of the DataConnection UI that allows to connect to ODBC, Oracle or MS SQL data. 

Connecting to the ContosoRetailDW database is simple then:

For a simple sample of a virtual relation let’s design a report of all the employees in the DimEmployee table and – per employee – all the customers from the DimCustomer table that happen to be born on the same day. The first step is easy, just drop some fields like FirstName, LastName and BirthDate from the DimEmployees table to the workspace to get the employee list. Next, click on “Append a Sub-Element” in the object tool window in order to add the DimCustomer table underneath. In the schema, there is no direct relation between the two tables, so choose “Link via Filter” from the new UI:

 

This allows to select from all the tables in the database (except the one you’re starting from). Select the DimCustomer table here and continue, select some fields for the customer database from the field selection wizard and go ahead. A message box pops up with a short description of what’s important to know when entering the filter condition in the next step. 

 

Assigning the required filter is dead easy in this case, of course. Note that the filter can be carried out on the database system in this case:

 

And printing the report nicely displays all the customers with the same birthday, highly performant. The “Demo” watermark is added in the demo application whenever you choose “Custom Datasource” as it would be too tempting to just use the trial version as a fully fledged SQL reporting system ;).

If you’re not using one of our components, you might have to adapt your printing code a bit in order to work with an empty relation name returned by LlPrintDbGetCurrentTableRelation() for a sub table. However, the required changes are quite easy to make (simply return the “full” child table in this case, filtered by the result of LlPrintDbGetCurrentTableFilter). And as one of the first questions whenever we add something new is “can this be switched off” : Yes, it can (LL_OPTION_COMPAT_PROHIBITFILTERRELATIONS).

 

What are your ideas for virtual relations? Can this solve some real life pain on your end as well?

Related Posts

Leave a Comment