In some cases when specifying simple conditions of filter group it turns out that it is better to use not the fields of table linked with the feature type, but the fields of query based on this table. Two situations of this sort can be used as examples:
If the table field contains the code with which the value from the reference table can be matched (see Chapter 27 “Reference tables”), then using the query in which a reference table is set allows using this value when specifying a condition. For example, instead of the street code from the table “Building Certificates” it is possible to specify the name of this street by the reference table “Reference of Streets”.
If a part of the data about features of the present type is stored in the table which is not linked with this type explicitly, but is joined with another linked table in the query using table join (see chapter 28 “Joining tables”), then this data can be also used when building a filter. For example, let's suppose that it is required to create a filter for parcels using the surname of the parcel owner. The table “Building Certificates” does not contain owners' names, they are stored in another table, “Parcel Owners”, which is not linked for the feature type “Parcel”. The query “Parcel Certificates with Owners” solves this problem.
However, it is not that easy. Sometimes, the result of using a query in the filter condition is far from expected or is not clear. For example, let the calculated field “Total Inhabitants” from the query “Allocation of Inhabitants by Streets” be used in the condition for buildings. The user can expect that as a result, the displaying style of a building will be determined by the total number of inhabitants in the street where this building is located. In fact, only the number of inhabitants in the present building will be taken into account.
To understand why it happens so one should understand the general algorithm of using query fields in filter simple condition. The essence of this algorithm is the following:
All records of the root table of the query linked with the present feature are selected. In case of a unique link not more than one record will be selected, in case of a multiple one – there may be several records.
All selected records of the root table are considered as a “temporary table”, and operations of building a query: joins, setting reference tables, calculations, etc. are applied to this temporary table (not to the whole root table).
Records of the query built in such a way are used for calculating the simple condition for the present feature. If the query contains more than one record, the specified variant of relations is used.
Now it is quite easy to understand why the total number of inhabitants is not summed up by all street buildings. There is only one certificate for any specified building, if any certificate at all, (since the link with the table “Building Certificates” is set as unique). That is why the “temporary table” contains not more than one record. The operation of adding the number of inhabitants by streets will be “addition” of the only item – the number of inhabitants in the present building in this case.
For the user who is afraid to get lost in the details of using queries when specifying filter condition we can recommend the following:
Do not use the queries containing calculations in the condition.
Use the queries containing joins only in the case if the join field in the root table is unique. It will permit avoiding difficulties arising for the join of the type “many to one” and “many to many”.
 |  |
