As long as the number of records less than 1000 I think you're quite safe.

>Naomi --
>
>First of all, my grids rarely work on cursors over 1,000 records, so response time has never been an issue. (I responded to this thread originally because of a comment about not using filters in grids because the scrollbars act odd).
>
>As for using SELECT statements to redefine the recordsource --- well, I guess I could, but one of the things I do is to allow my users to select from any column from any grid they see. They can always right-click on a column and, among other options, can choose records they wish to select (it recognizes four different datatypes for selection-- character, numeric, date, and boolean). The column class then only needs to set the filter for the recordsource, and need not know how the recordsource is created. Multiple selection criteria can be entered (value > 1,000 since March 15th, for instance).
>
>This could be replicated using SELECT statements, of course, but it gets kind of messy when the controlsource for the column is a field from another table (such as the part description from the parts table). It's quite a bit of work to determine how to duplicate that when constructing the SELECT statement. There's also problems when the controlsource is a calculated field, since it may reference field names that make no sense in a SELECT statement
>
>There's another issue as well, and that is keeping the user at the same place in the grid when he changes the filter. This involves both keeping the same record and the same column. Keeping the same column is important to me as many of my grids have more columns that can be visible at once (sometimes by design, sometimes because the user has selected more columns than can fit). Obviously I haven't investigated what happens when you re-create the recordsource, but it would be one more minor thing to get right.
>
>I also a mechanism I refer to as a "filter table", which is a two-field table having unique values from some column in the record source and a boolean field. I set a relation from the record source into this table, and the filter for the record source then simply includes selecting records where the boolean field is .T. This technique works quite well ... presumably easy enough to replicate in a select statement, but I haven't seen a reason to.
>
>Jim
>
>>>Naomi --
>>>
>>>I don't use grids to work on tables. Little of my usage has to do with merely presenting records from a table in a grid, as most of my grids create and use cursors that are summary information from tables.
>>>
>>>Within this rather limited use of grids, filters can be quite beneficial. I provide my users with a number of different alternatives for effectively modifying the filter so that they can choose the records they're interested in. Some of these alternatives are generic for all grids and thus have no specific knowledge of how the underlying cursor was created.
>>>
>>>I'm interested in investigating your reference to filtered indexes (not a familiar topic) to see how they can help.
>>>
>>>Thanks,
>>>
>>>Jim
>>
>>Jim,
>>
>>We used similar mechanism, e.g. user can chose one of the predefined filters to limit number of records. The problems arise than only small subset of records satisfy the filter criteria. The grid movements became painfully slow and the scroll bar misbehaved. That was in VFP6, I'm not sure if it's better in VFP9 (should be according to VFP documentation). If you're using cursor to display data in grid, can you just have your original cursor with data and use select statements to generate temp cursor for grid's usage?
>>
>>In one of my application (or few, don't remember details now) I used indexes with filters. They worked better than plain filters.