Use the property Data Filter to also define a filter condition for report container elements. Only the records matching the condition are displayed in the object or element.
The filter condition – depending on data source and application – will be checked for compatibility with the database system and then executed there completely or partially. This can result in a considerable performance increase.
There are three different modes for a filter:
1. Full compatibility to database. Many of the built in functions can be fully translated to native database statements. If the data source, for example, is a SQL Server, many operators and functions can be supported (Left$, Right$, Mid$, Round, StartsWith, EndsWith, Contains, Upper$, Lower$, Year, Month, Day, Len, Empty, DateInRange, NumInRange, Artim$, LTrim$, RTrim$). Microsoft's SQL Server can support some additional date functions like AddDays, AddWeeks and the like.
Figure 7.20: Full compatibility to database
2. Partial compatibility to database. This means, a part of an expression can be translated where another part (that is concatenated with "and") can not. In this case, the supported part is done using native filtering whereas the unsupported part is done by the reporting engine.
Figure 7.21: Partial compatibility to database
3. No compatibility to database. The filtering is performed by the reporting engine. You should try to change the filter condition to a supported syntax.
Figure 7.22: No compatibility to database