It's somewhat difficult question for me, because I rarely use both filters and local views :). To be precise I practically never use formers and just sometimes use latters, so it's hard to compare. IMO, filters approach (besides commonly mentioned grid problem) requires specific way of designing application flow, i.e. it might be doable but somewhat outside of standard approach. In pratical area, it's enough to say that SELECT-SQL doesn't respect filters, i.e. query time will be always the same.

>Thanks for the info.
>
>re #2 - Do you have any specs or anecdotel evidence on how much faster VIEW's are than the FILTER command? I am trying to decide if I should rewrite:
> - all my parent/child stuff;
> - just my parent/child grid stuff, or;
> - the parent/child code for the grid the one grid I am having probs with.
>
>
>>>In a previous thread for a related topic, the clear concensus was that Parameratized Views are better than the FILTER command. I have three (simple?) questions about View's vs Filter that I can not locate documentation on.
>>>
>>>1: I am writing for a shared environment. I thought (from FP2.6) that SELECT (or any other SQL) could not be used in a networked/shared environment because it required Exclusive access. I created a test and noticed that the EXCLUSIVE property in my TESTVIEW was set to YES but my tests on my LAN seem to indicate that this is not a problem. I think EXCLUSIVE in this case relates to the VIEW, which is specific to each machine and therefore does not cause a problem (i.e. the use has exclusive access to a file(view) which is only on their machine anyway). Are there any networking issues I should be aware of with SELECT?
>>
>>Actually, there are no problems here. Make sure that tables already opened when you fire SELECT-SQL (just a precaution). Exclusive usage is really applied to view only.
>>
>>>2: As almost everyone has pointed out, it appears that the p-view is very fast. Is it faster that FILTER in all/most parent/child circumstances or is it just faster for grids? Basically, I am trying to decide if I should adjust the code for five large and complex main forms I already have written.
>>
>>It's mostly grid's problem. Other things depend on way you develop your application.
>>
>>>3: I found that unless I set SEND SQL UPDATES on in the View Designer, that the updates did not get sent to the base table. I was using TABLEBUFFER = 3-OPTIMISTIC ROW BUFFERING, and TABLEUPDATE(.T.) in my SKIPx commands. I think the TABLEUPDATE only updated the TESTVIEW info with its related cursor info. Is there anything I am missing here or is SEND SQL UPDATES the only thing I need to know?
>>
>>Yes, 'SendUpdates' is a requirement. Buffering setting handles how updates will be send to tables.