Hi!

Well, for sure it is a good idea to move from SET FILTER to views.

First of all, SET FILTER commands in complex environment during development cause a lot of overhead and complexities just to correctly set filter for each table. With views it is much easier.

In grids SET FILTER conditions are not optimizable despite indexes. This is because grid uses GO TOP and GO BOTTOM commands when coming to top or to bottom of gris records, and these commands are not optimizable when filter is set. So, when you have a grid and al 10 records are displayed in it, grid becomes extremely slow when table has 10,000+ records.

Without grids, filters are ok. There is also another point of view - get rid of editing data in grids at all. Anywaym grid is a good tool just for displaying information, so results of read-only query (eitehr in form of view or in form of a cursor) could be displayed anyway for quick searching or navigation through records.

The real solution is dependent mostly on the quality of iterface, its features, requirements to it etc. Good interface with good performance takes more time for development and design, just because special approaches and features. In such case it is recommended also to use some sort of framework - many frameworks has built-in tools to help building such applciations.

So, when it is posisble to spend more development time on change, I recommend to get rod of editing in grids and use better interface approaches.

If there is lack of time, changing from SET FILTER just to local views is a good idea, but only for places where data are displayed or edited in grids. In places where data are not edited in grids, it is doubt if to use SET FILTER from performance point of view. (Just a note - instead of GO TOP or GO BOTTOM commands, use LOCATE command, that is optimizable for conditions in SET FILTER expression.) Sometimes, when there is a complex data processing, it is better to use local views instead of SET FILTER. This is because indexes loading through network during optimization process, that could be slower than just using of local view. On the other side, processing of data by local views might require additional indexing, processing of updates/transactions etc. - decision here should be made separately for each particular place. So I agree that some bechmark is a good idea.


>Hi everybody,
>
>Our framework is VFP native tables oriented. I have some ideas, how to modify it to allow to work with P-Views. I need to convince my colleague and my manager, that it's important decision and it should be made soon...
>
>Here is the letter, I've just written. I'd like to see your additions and more "scientific" arguments to it. Thanks in advance.
>
>
>Hi everybody,
>
>It's a well known fact, that filters could be painfully slow, especially if grid is used for editing, like in BldMstr Editor, Address Standardization, Names and other applications. Also it's well known, that SET FILTER is a command, which can work with VFP native tables. If we later decide to switch to another back-end (like SQL Server, for example), we will have to re-work our framework and all our forms.
>
>Users are complaining that our applications operate slowly. We watched this slowness with Alan couple of times... This slowness is especially visible, when filter applies to only few records in a file (say, 10000 recs. and only 10 records are "bad"). The scroll bar in the grid doesn't behave properly, because it knows nothing about the filter.
>
>So, the solution would be to switch to P-Views (updatable). This idea would require some changes in the baseform as well as changes in some of the applications. The benefit would be obvious, once we'll take this route and make our applications scallable.
>
>I don't want to write down at this moment all ideas, which changes in framework it would require or how the individual applications should be changed (I thought this idea through to some details).
>
>At this moment I'd like to hear from you, what do you think about the idea in general and when (if either) we're going to proceed with it?
>
>Thanks a lot in advance.