Reporting - Filtering Enhancements

For our upcoming v18.1 release, we have implemented two sets of improvements to existing data filtering functionality. We’re touching two completely different areas here, from end-user UI to low-level parameter representation and transfer.

Improved Filter Editor

The first group of changes applies to the text mode of the Filter Editor, which is used to configure client-side filters. The most important property that uses this editor is XtraReport.FilterString, but it is also used by Parameter.FilterString when creating cascading report parameters, and by the XRPivotGrid.Prefilter.Criteria property.

These are the new features of the Filter Editor:

• Code completion and syntax highlighting help you enter valid expressions quickly:

• Column and function tooltips make it easy to refer to element details while the editor is being used:

• Input validation is much stronger than in the past, and errors are shown immediately when they occur:

Using multi-value report parameters with queries and stored procedures

In the past, we did not have direct support for use cases where multi-value report parameters needed to be mapped to query parameters. A workaround existed that used the DataSourceDemanded event, but it was necessary to write code for this event handler.

We are now adding the ability to handle these scenarios automatically. Things are very simple for SelectQueries— check out this expression:

[Orders.OrderID] Is any of ?OrderIDs

This is what the Filter Editor might show if a parameter is used (?OrderIDs) that represents a list of values, not just one value.

What about stored procedures and custom SQL queries?

Stored procedures are a bit more complicated, because you can’t pass a value list to a stored procedure directly. For this purpose, we are introducing the expression function Join(), which can combine values for you. On the server side, you need to parse the combined parameter string, which depends on your RDBMS of choice.

Note that if you allow your end-users to create custom SQL queries, these are executed in the database server context just like stored procedures. Therefor, the mechanisms described below need to be employed in any custom SQL queries that work with multi-value parameters.

For instance, on SQL Server you could do something like this (note the STRING_SPLIT part that “converts” the values, be sure to check Microsoft’s notes about it!):

select * from Orders
where OrderID in (select value from STRING_SPLIT(@data, ','));

On SQL Server, it is also possible to use stored procedures with table-valued parameters, together with our new CreateTable expression function.

As a second example, here is a MySQL stored procedure, somewhat more elegant due to the availability of the find_in_set helper:

create procedure `get_movies`(in titles varchar(100))
begin
   select *
   from movies
   where find_in_set(title, titles);
end;

You can find documentation of the process at this link, including sample code for several different scenarios, and here are more details about the Join and CreateTable functions.

Of course we always appreciate any feedback you can give us! Are these new features going to be useful to you?