Mike,

Ofcourse getting all records will slowdown the system but since they're using SET FILTER, they don't want to get all records :)

But to support Nadya with her suggestion that RV is a better option, I would like to share my personal observations:

We are using RVs querying millions of records and I noticed that there is only an slowdown if the number of records being queried are thousands. If only a few or hundreds the slowdown is insignificant. Ofcourse, full rushmore was applied. Below is an example:

t = seconds()
Requery("patinv") && 2M+ records getting 1 record only
Requery("patitem") && 2.5M+ records getting 10-15 records
Requery("patpay") && 200T+ records getting 5 records the most
Requery("patpayitem") && 300T+ records getting 10 records
Requery("patdoctor") && 200T+ records getting 2 records
Requery("patgntr") && 300T+ records getting 2 records
x = seconds()
wait window str(x-t)

Above block of code only takes 2 to 4 seconds during first execution and 1-2 seconds succeeding executions.

Updatable Views have intermittent problems that's why JVP is calling it as lousy method of manipulating data but to me, after painful research on how to solve RV specific problems, RV is the most easiest way of doing C/S applications with VFP.

>Hi Nadya
>
>No solution is perfect. You may want to look at SET KEY as an alternative to SET FILTER for the places where your application is slowest. Views have a problem too. If the user demands all records from a large table, they will have a long wait. Of course, the trick is to prevent the users ever getting all records <g>.
>
>
>>>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?
>>>
>>
>>It's a good idea, I will run some tests to prove my point. Our framework is table-oriented, it has FILTER method, which sets filter and also in Init of the form there is SET FILTER command. My idea would be to add new form's property like ViewUsed and update these two places accordingly, so it would behave the same way as before if this property is set to .f., but will have new functionality otherwise...