Hi all.

Since I wrote 2 Foxpro Advisor Articles on Rushmore, and my first was to complain about this very problem, I'd like to point out some things. SET FILTER theoretically scans the index, and builds a bitmap indicating which records met the condition and which didn't. The Browse command theoretically uses this bitmap to present records until the display is full. It also stops when it finds no more records to display. LOCATE and CONTINUE theoretically uses this same bitmap.

The grid doesn't do this at all. The grid seems to assume that the data set has already been extracted via a Rushmore optimized SQL / View. If you have a large number of records and a filter that results in a small number of records to display, the grid will spend significant time looking for enough records to fill the grid's rows.

The issue here is client/server friendly approach versus the "traditional" approach. The grid is trying to be client/server friendly. Therefore it doesn't have to be Rushmore aware (but I still wish it was <g>)

My second article shows that in a truly client/server environment (with a backend like SQL-Server or Oracle) that since the data sets are already "filtered" by the backend prior to being sent to the PC, Rushmore is redundant and actually causes a performance hit.

I tried with some success in my first article to use every trick I know about Rushmore to offset the grid's natural tendencies. Oswald Peterson (en?) wrote another article in which he built filtered indexes to get around the grid's design. However, with a large dataset, waiting for indexes to be built could be tiresome.

So, John Groft (the originator of this thread), my reluctant advice is 1 - use remote views to extract only the data the the user should see (never show the entire list) or 2 - build another grid control or 3 ask Microsoft to add methods to the grid which we can override to expose its internal record navigation/display technique.

Mike Yearwood