>
>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.