>>Set filter is greatly enhanced but I still keep it in my "commands not to use list":)
>
>why may i know ? and what is the alternative? SQL joins?

That's one. Another one is basing your grid on a cursor you created, and then zapping that cursor and inserting only desired records into it - which is blazingly fast, and in case of larger tables may actually work better than a filter. The additional benefit is that the scrollbar on this cursor's grid works right.

>any specific conditions where it leads to errors ?

Counting records, trying to locate records etc will respect your filter - now if some component of your form is not aware of the filter, it may not be able to find a good record because it's filtered out. Also, when adding records, if the grid on a filtered set refreshes while a new record is added, the new record may be filtered out before its fields are filled, if the currently filled fields don't satisfy the filter conditions. You can see that in a simple browse for - if you browse for fld1=1, press ctrl-y to get a new record, then you move off that record before you entered 1 in fld1, your new record is gone. It's there, but filtered out.

IOW, you're getting a now-you-see-me, now-you-don't situation which makes your life interesting.

I used a filter in a couple of places for exactly the same purpose - to limit the number of records displayed in a grid, and the end user had to live with a few limitations, and I know the trouble I had. If I had to redo that today, I'd rather create a view with a special condition than use a filter.