FrankThynne
Technical User
I have been caught by the limitation that TQuery.Filter expressions can compare columns with constants but not with other columns. They do not support arithmetic or calculated fields either.
The problem arises because I'm trying to produce a result set in which the user can tighten or relax the query conditions at run time. For example, on checking or clearing a check box the user should be able to add or remove the condition 'Columna = Columnb', or add or remove the condition 'Columna-Columnb-Columnc > 0'.
At present my only work-around is to have different queries for these conditions, which requires me to close and reopen the TQuery objects which introduces an unwelcome delay in responding to the user action.
I should explain that the 'columna=columnb' case involves additional terms in a join expression (which is a bigger overhead if I'm changing the SQL). The 'Columna-Columnb-Columnc>0' case applies to the data from one table. In both cases, I can't see why the filter (which is applied locally, I believe) should care how the columns are produced.
And, yes, I've tried calculating the arthmetic expression in the SQL and using the resulting column in the Filter: that isn't supported either!
The problem arises because I'm trying to produce a result set in which the user can tighten or relax the query conditions at run time. For example, on checking or clearing a check box the user should be able to add or remove the condition 'Columna = Columnb', or add or remove the condition 'Columna-Columnb-Columnc > 0'.
At present my only work-around is to have different queries for these conditions, which requires me to close and reopen the TQuery objects which introduces an unwelcome delay in responding to the user action.
I should explain that the 'columna=columnb' case involves additional terms in a join expression (which is a bigger overhead if I'm changing the SQL). The 'Columna-Columnb-Columnc>0' case applies to the data from one table. In both cases, I can't see why the filter (which is applied locally, I believe) should care how the columns are produced.
And, yes, I've tried calculating the arthmetic expression in the SQL and using the resulting column in the Filter: that isn't supported either!