Hilmar,

If I would have a choice, I would not use SET FILTER for the grid. Period :)

>OK, but that is just what I was saying: that the filtered grid becomes slow if there are many records in the table. I do NOT advocate a filtered grid for child record (user-defined filters are something different), unless there are relatively few records (I decided to put the limit at 20,000), and the table is not expected to grow beyond that limit.
>
>>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...