Reporting Module Filter Key: Fix Empty or Unfiltered Tables

What is actually wrong with the Filter Key?

The Filter Key on a report Table is not a search box. It is an expression that the report engine evaluates once per row, and it keeps only the rows where the expression returns true. Typing a bare value such as Engine 1 returns no rows. Writing engine = "Engine 1" returns every row. The form that works is the Java-style equality comparison engine == "Engine 1", where engine is the column key from the query and "Engine 1" is a quoted string literal.

How do you read the symptoms before changing anything?

Look at the output first. The rendered table tells you which stage of the chain failed: the data source, the key name, or the expression. Three outcomes are possible. If the unfiltered table shows all engines, the query and the data key are good, so the problem is in the filter. If the filtered table is empty, the expression evaluated false for every row. If the filtered table is identical to the unfiltered one, the expression did not restrict anything, so it evaluated true for every row or the engine ignored it.

Why does a plain value or a single equals sign fail?

Follow the value through the chain. The query produces a dataset. The Table iterates that dataset row by row. For each row, the engine resolves the keys in the Filter Key expression against that row's columns, then evaluates the whole expression. The row renders only if the result is boolean true.

A bare string such as Engine 1 is not a comparison. Nothing ties it to a column, so no row can evaluate it as a match, and the table renders empty. The single equals is the more misleading case. Keychain expressions use Java-style operators, and in that notation = is not the equality test. The expression does not do the comparison you intended, and in practice the table came back unfiltered. Only == performs a value comparison that yields true for Engine 1 rows and false for the others.

The same operator rules apply to the rest of the expression language. Use != for not-equal, && and || to combine conditions, and relational operators for numeric columns. The keychain expression documentation lists the full operator set. Check it before assuming an operator from SQL or from a spreadsheet formula will carry over.

How do you build per-engine tables that filter correctly?

The design is one query that returns all engines, with multiple Table components on the page, each filtering its own engine. Tuning the query does not fix a bad expression, so verify each link in order.

1. Confirm the data. Preview the report with the Filter Key blank. Every engine's rows must appear. If they do not, fix the query or the Table's data key before you touch the filter.
2. Read the exact column key. In the report's data browser, note the column name exactly as the query returns it. If the SQL uses an alias, the alias is the key. Match the spelling and case.
3. Enter the comparison in the first Table's Filter Key: engine == "Engine 1". Type the quotes as plain straight double quotes. Do not paste them from a word processor or a web page.
4. Preview the report and confirm that only Engine 1 rows render.
5. Duplicate the Table for each remaining engine and change only the literal, for example engine == "Engine 2" and engine == "Engine 3".
6. If the engine list changes over time, one hard-coded table per engine becomes a maintenance item. For a variable number of engines, consider grouping or a per-engine query instead of adding tables by hand.

How do you verify the filter is doing the work?

Measure against the unfiltered baseline. Count the rows for each engine in the unfiltered preview, or run a GROUP BY count on the source query. Then confirm that each filtered table shows exactly that count. The per-engine totals must add up to the unfiltered total. If they come up short, some rows hold values that fail the comparison, such as extra spaces or different case.

Next, run a negative test. Temporarily set a filter to a value that does not exist, such as engine == "Engine 99". The table must go empty. If it still shows data, the filter is not being applied at all. Recheck the operator and confirm you edited the Filter Key on the correct Table instance.

Which pitfalls recur with report filter expressions?

• Curly quotes. Text copied from formatted documents often carries typographic quotes (“ ”). The expression parser does not treat them as string delimiters. Retype the quotes by hand in the designer.
• Whitespace and case in the data. == on strings is an exact match. A database value of Engine 1 with a trailing space, or engine 1 in lowercase, will not match "Engine 1". Trim or normalize the values in the SQL rather than in the filter.
• Type mismatch. If the engine identifier is numeric, compare it to a number (engine_id == 1), not to a quoted string.
• Stale key names. Renaming a column alias in the query silently breaks every Filter Key that references the old name. The symptom is empty tables everywhere at once.
• SQL habits. Single =, AND/OR, and single-quoted strings come from SQL, not from keychain syntax. Write the filter in Java-style notation.

FAQ