The query app is subject to pretty much the same limitations as the base editor is. As a rule, if a column can be filtered (not all can), the column can be queried in the query app. Exceptions apply.
The long text column is such an exception. Why? Keep in mind, the character limit for a single cell is 100.000. This is a lot of text! Filtering over such a column may be very heavy. For this reason, the available filter operands for the long text column are only “is empty” and “is not empty”. And you cannot sort by the contents of the long text column. In the query app, the long text column cannot be added as a query field. Sorry.
my use case:
I want to build an employees directory with their job descriptions.
with 3 groups:
a group for the executive board: providing the list of departments as CDS;
a group for the HR department with list of employees shared as CDS (without salary column);
a group for all employees, with a base called job description, which combines the two CDS.
The advantage: the list of departments is managed in one central place, and thus changes only need to be made there.
At the moment, due to the query restrictions, I made one table with departments as “single select column”. The problem: when I will create another table with a departments column, I need to define them again inside the table.
@rdb : do you have any plans to address these limitations on your roadmap?
thanks for your help!
Cascaded single select columns work perfectly fine in tables and forms.
However in Query Apps, no matter which parent option is chosen, all child options from all parent options are shown.
This can be very confusing and lead to meaningless queries.