>>I use filters in child grids (when there is a parent-child relation), and I didn't notice any problem, apart from the speed problem, but only when there are scores of thousands of records. Did you notice any additional problems?
>>
>
>We used a filtered table. If only few (~20) records satisfy the filter condition out of, say, 10000, the grid starts to behave so slowly, that it's a real pain to see the users working with it. The filter is a feature for application. E.g. suppose the users are doing address standardization. At first they run the Auto process. This process cleans most of addresses. Then they need to resolve couple of bad records. They have a choice to set a filter to see only the bad ones or work with the whole unfiltered table (the bad records are shown in red)... The implementation of filter is generic and it's build in our framework form class...

I have one application where I still have a huge grid (about 14 columns, 30 visible rows, 30000 records, a bunch of dynamic colors) and ad hoc filtering...
BUT
I always filter on the same (logical) field, which is indexed. Since this is a single-user application, and filtering would have to go through the whole table anyway, this way I at least do it in only one pass:

set filter to
blank all field lIsInFilter
replace all lIsInFilter with eval(cFilterExpr)
set filter to lIsInFilter

This way, I still get the usual delay while applying a filter, but after that the navigation is nearly instantaneous, and I know my filter is optimized.