Hi Nadya,

So you're saying that they always use SET FILTER on a table rather than a parameterized view? Ouch....

I think you made some good points in your letter. Why not take a huge table and do some benchmarks between SET FILTER and a view?



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