SET FILTER is pretty good. I used to use it a lot. However, since I normalize data a lot I cannot use it with multiple related tables.

The SQL engine has never been worse than the set filter for complexity. See Sys(3055)

Either use the SAFE SELECT technique,
query to a second cursor
then zap your grid's cursor
append into the grid's cursor from the second cursor

OR

remember all the grid's recordsource and column control sources,
set the grid's record source to ""
fill the grid's record source
re-establish the grid's recordsource and column control sources.

OR

use cursor adapter


>>>
>>>I don't think this will work. If I use SQL against it it would recreate the cursor, so all data enterd until then would be lost. I have never played with the SQL of a view or CA while it's loaded, will this work? At least the view would not work.
>>>
>>>The only problem with the Filter and the grid is the akward behavior of the scrollbar (Basically the total height of the scrollbar is bound to RECCOUNT() ). One can bear it.
>>>
>>>Sorry, but SET KEY is a laugh. I simply can not have a tag to each and any possible combination. It's not like filtering for one field. Even one char field could be filtered for inlist like $ = and ==. Any conjunction of fields is allowed. Also it would reorder - what is not a good solution too.
>>
>>I don't understand the sentence "If I use SQL against it it would recreate the cursor, so all data enterd until then would be lost". SQL causing data loss?
>>
>>I don't use views, but with CA you can simply use parametric SQL (as well as with views) and it works wonderfully well. If say you had millions of rows in an SQL Server backend, what would you do for this? Bring down all the data down the wire and then filter using "SET FILTER"? Not even millions, you wouldn't want to do that with 20K rows, no? Using SQL you can control the filtering and ordering as well.
>>
>>I agree that SET KEY has a very limited use case, but I still think it is still a better option than using SET FILTER. If you think about it, SET FILTER was not even optimized up until VFP9. And just for fun, try using an expression having DateTime in it, around midnight with SET FILTER. I can't bear the visual discrepancies SET FILTER creates.
>>
>>And also, the data used in grids are 99% readonly, you edit the data outside grid, a simple SQL cursor is the perfect record source.
>>
>>I believe many experts have "SET FILTER" in their "not to use" commands list.
>
>Hi Cetin,
>
>thanks for your thougts
>
>I know there are considerations - but they are not on my use.
>
>The unfilterd cursor in the grid is a result of as lot of dataprocessing anyway. It could be several 10 k records if the possible presets are set unwise - or by intention. There are some uses of that. Not that I like it, customer likes it.
>
>If I change the data within a grif or in objects outside the grid does not matter. Sometimes I update (replace) several k records at once and process (tableupdate) later. So like working in a list and process the list later on. That's the way customer likes it. He filters / alters single records groups of records on his needs. So if I requery the cursor bound to the grid I would reread and all data entered would be lost.
>
>Optimization? People are bound to wait on web data nowadays - the slowest dektop SET FILTER is faster by an order of magnitude at least.
>
>There are such and such experts. I know a lot doing SET FILTER. Don't need to argue on that. :)
>
>I will look at changing the SQL on the fly. Go you alter the SELECTCMD of the CA? Or do you argue about variables to parameter a where clause? I can not set up a higher ten possible fields to query. Not for a single "=" comparsion and not on a variety of LIKE = == $ INLIST operators. 6 parameters per field, ICASE to determine? VFP's SQL engine will die with C0..05 on complexity. That I know for shure. SET FILTER uses only the active ones or none, that's a lot faster and less complex.