>>I use p-views when using tables of 20,000 or more records. The largest table now has more than 100,000 records, and I have no problems.
>>
>>The key is to show only a small subset of the data, and to optimize the view. I do not mean Full Rushmore Optimization - partial optimization is often faster (see my FAQ on Rushmore, for details).
>>
>>I don't even consider 100,000 records as "large" - for VFP, and today's computers, that would be medium, at most.
>>
>>OTOH, a filter is very slow if used with a grid.
>>
>Thanks for the feedback, Hilmar. I suspected as much. And I realize 100,000 records is not really "large" by VFP standards, just large for me and my experience.

That's right - even maintenance tasks like PACK can be done within a reasonable time. The fact that users use the system all the time is far more troublesome than the mere size, in this case (I do most maintenance at night, with automated procedures).

>How do you handle indexing your p-views? I want to maintain the incremental search and grid header click to set table/view order.

You can create a temporary index on a view. In fact, the framework I use (Visual Extend) does this automatically, for the very purpose you mention. That is, if an index on the desired expression doesn't exist, the framework creates a temporary index. This works on tables as well as views.

If your p-view fetched only 100 record out of the total of 100,000, only the 100 records have to be indexed (the view result, in this case, is a temporary table with 100 records!), so this is very fast.

To avoid interference with other users on the network, or with other sessions, use sys(2015) to generate the index name.

HTH, Hilmar.