Jim,

>I do the same thing with views, I don't use SET FILTER especially with grids as the grid's handling of a filtered recordsource completely removes any advantage of optimization.

>I stand by John's original SET FILTER being one of the VFP things to avoid.

hmmm.. I tend to use row-buffered tables for maintaining the main tables like (employee, articles, clients) etc. For one-to many relations I use table buffered p-views. Here I'm able to change all artibutes (including the data in the one-to-many relations) and could undo them simply. The user can browse freely within the main row-buffered table (within a grid), until they change some data regarding this entity. However I still do allow the user to filter the table on a custom expression. How would I do this since I can't requery the the main table if it is a p-view.

Second drawback is that you must predetermine the filter on the data before you display the form, or else the whole entity table is queried (talk about a performance killer). Therefore I display the whole table in a grid (superfast) and the user *might* filter them on whatever they want, (which *CAN* degrade performance). Since the norm is to display the whole table, and they have the *posibility* to filter the table, SET FILTER is the most logical choice here.

Of course SET FILTER is of much value in FPD FPW 2.x systems.

I agree that SET FILTER must be used carefully because there are certainly circumstances where p-views are much more convinient than filters, but p-views can't directly be compared with seting filters; there are many differences between the two and the advantages do not only apply to p-views.

In my case, I've found some circumstances where I definitely don't want to use p-views (and performance is also an important issue) and where SET FILTER solve the problem nicely

Walter,