Daniel,

>Nadya is correct when she states that filters can dramatically slow down a
>grid's performance.

I wasn't disagreeing with that point.

>Furthermore, there are instances when you have to use a filter and cannot
>query again. For example, if you allow the user to change multiple records
>at one time and view the effects of the changes on a particular subset prior
>to saving or cancelling the changes. This type of interface is often
>encountered as a requirement when you develop software to evaluate scenarios.
>

I don't particularly care for grids (or BROWSES for that matter). With a grid, doing data validation can be difficult. With a BROWSE...I wouldn't go there period.

In practice, I use grids as basically read-only browses, but with some additionally built-in sophistication (re-ordering by clicking the header with remote views, for example). There are other instances where I use grids (a parent-child-grandchild relationship), but that's something I developed to help the stuff I'm doing with SQL-DMO.

In the original question, the output from a query. I made the assumption that only a small portion of the dataset would be returned and, as Steve Gibson mention, some code I had recently posted (using a grid) might be a good choice for a solution. Nadya then mentioned that it might be problem if a filter was used. From my POV, I'd be far less likely to use a filter when an SQL statement is already being employed.