Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Set Filter performance in Browse versus Grid
Message
De
26/10/1999 11:59:28
 
 
À
26/10/1999 11:28:11
Mike Yearwood
Toronto, Ontario, Canada
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00279680
Message ID:
00281549
Vues:
18
Hi Mike,

SET BrokenRecord ON

That's a nice explanation of why the Grid (probably) acts as it does.

Too bad that the Help doesn't care to mention anything at all about this aspect of Grids, especially given the focus on PERFORMANCE that all of us expect from VFP!

In fact I would put the Grid Help as about the WORST of all of the Help, given the complexity of the object.

SET BrokenRecord OFF

Cheers,

Jim N

>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
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform