Hi Vlad,

First of all, thanks a lot for jumping into this thread. Bellow are my comments.

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

Right. I found extreme slowness when few records satisfy filter condition. Here is our typical application scenario:

Consider Address Standardization in Parcel Processing:

1) The processors don't have to standardize the whole file, because most properties stay the same, so addresses don't change and they were standardized in the previous year. So, the one "invisible" filter at the beginning of the process would be to filter only "new" properties.
In our base form terminology this would be FilterStrHidden, which is set in Form's init. Usually file has 10K-20K records and ~ 1K should be reviewed.

2) The next step would be to parse and perform Auto Address. These two processes automatically correct possible problems and ~85% records now don't need any work.

3) So, user now wants to filter "Bad" records. He/she presses filter button on navigation bar (in our system it's a container at the bottom of the form) and chooses Unresolved records (marked in red forecolor in grid). Usually it's ~10 -200 records from 1K. And now system behaves painfully slow.

I can send you some screen shots of this application, if you'd like.

>
>Without grids, filters are ok. There is also another point of view - get rid of editing data in grids at all. Anyway grid is a good tool

Users find convinient to make changes in grid directly. I'm not sure, what kind of alternative interface I can provide. Additional form for editting?

just for displaying information, so results of read-only query (either 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.
>

We have our own framework. I'm not sure from which framework it's originated. It's still buggy and it also is table-oriented. I want to make it view-oriented as well. Basically, I want to add a new property to BaseForm, which will control how the form would operate. Only two methods would be really affected by this change...

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

What kind of approaches would you recommend? Could you please send me few screen shots of your applications?

All we build here is for in-house operations. We basically have the following operations:
Parcel Processing
Transaction Processing
Getting Data out to the customers
Database maintenance operations.

In Parcel Processing they do Address Standardization (Property and Owner site), Names standardization, Zipping, Validations, Calculate Taxes, etc.

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