With all due respect to everyone here, my original point was that performance of a grid with a FILTER should be somewhat comparable to the performance of a BROWSE with a FILTER. Here is my reasoning:

- I considered that the SET FILTER command might be inherently slow. However, setting a FILTER condition and simply issuing a plain BROWSE command displays records quickly. I agree that the BROWSE window probably only retrieves a certain number of records which makes the performance seem faster. However, just try pressing the down arrow key or the Page Down key. Those additional records are retrieved very quickly (assuming that the tables are local). You can scroll through the records with no noticable delay. (Besides, wouldn't the GRID the same type of smoke and mirrors to produce the illusion of speed?) I believe that the FILTER condition is most probably slower than a parameterized view because of what it does, but if the performance degradation I experienced was due to the FILTER condition itself, the performance should have been slow in the BROWSE window as well.

- I considered that the GRID might be inherently slow. After all, it is a container that houses MANY objects. However, there are two holes in that theory. 1) Without the filter condition, the grid performs very fast. 2) A BROWSE window is comprised of those same objects - as evidenced by the fact that you can use the NAME command to manipulate them.

Given those facts, it seems evident to me that, if performance of a FILTER command is so much slower in a GRID (and I stress *so much*), that there has be be some additional overhead that the GRID applies when a FILTER condition is in effect. So far, Marcel's explanation seems to be the most plausible to me.

In any case, thanks for all the input. I really appreciate the responses this question has generated and I think that it's provided me with the solution that I needed.


John