>I've seen arguments about using p-views here, but I've got serious problems with that. P-views cannot replace all functionality of SET FILTER:

P-views can't use buffermodes none and pessimistic row and table buffering

None is unavailable because it is impossible to get a view to directly update its source "on the fly". Pessimistic locking is non existatnt in the sense of client-server systems. The equivalent functionality can be provided for the pessimistic stuff.

You can't refresh the p-view when you've got modifications in the view.

So what? You can use the view to provide the set of records and then relate it into the table and directly edit the table. However the whole design will go ot hell in a handbasket once the system moves to C/S. Why would I want to purposely design an application today that cannot go to C/S without the data handling being completely rewritten?

You can't use the original indexes of the source table. Though you're able to create temp indexes, they'll give a problem within transactions.

As you said, you can create indexes on the view if you need them. I find that 9 times out of 10 the data only needs to be in one order so I just use the ORDER BY clause of the view and let it go at that.

P-views generates a temp table, consuming CPU cycles, disk I/O and memory, giving serious performance problems with larger tables.

Hog wash! I have tested views against direct file processing and the data retreival may be slower, the same, or faster than the xBase equivalent depending on what is being done. However, in the tests I have run and the tests others have run the difference when there is one is usually very small.

I assume that you never read Malissa Dunn's book for the 1st The Pros Talk Fox series on SQL. She compapred xBase equivalent syntax to every SQL she demonstrated and published the performance times. Her findings bear out what I just said. The number of differences are equal to both approaches, sometimes xBase is faster and sometimes SQL is faster but in all of them the difference was minor. There were only a handful of situations where either of them was considerably faster than the other and those were also evenly divided between the two approaches.