>Hello Dragan,
>
>This is just besides the main point but I am curious, did you get any performance boost by indexing on the logical field?
>
>If not, why did you resort to it?

The purpose of that field is to be indexed and filtered on, nothing else. And it serves that purpose fine.

As to the other question, I didn't even try to do general-practice filtering without it for this table. I've written several custom filter builders over the years, and used a few of those coming from frameworks. As long as you stick to indexed fields in your filters, you're doing fine. However, the more you use other fields, the worse it gets. Slower, that is. The filter on unindexed field is evaluated on each record until the visible part of the grid is full; if your user scrolls up and down a lot, they will be evaluated over and over. Just include in the filter expression an udf which will count how many times was it called, and you will get some idea.

I also knew in advance, in this case, that the filtering requirements will grow. In the end, I had a few filters with criteria coming from child tables, even some calculations etc. So the only reasonable filtering I could do was to get a set of primary keys of the records satisfying the criteria into a cursor, and then update mytable set IsInFilter=.t. where pk in (select pk from temp). This works perfectly, and I don't even dare think how slow (or impossible to do) would all of this be if I tried to do the filtering based on an expression.