Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Filtering records in grid
Message
 
 
À
03/06/2004 17:41:35
Dragan Nedeljkovich
Now officially retired
Zrenjanin, Serbia
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Divers
Thread ID:
00909441
Message ID:
00909724
Vues:
13
>>>I use filters in child grids (when there is a parent-child relation), and I didn't notice any problem, apart from the speed problem, but only when there are scores of thousands of records. Did you notice any additional problems?
>>>
>>
>>We used a filtered table. If only few (~20) records satisfy the filter condition out of, say, 10000, the grid starts to behave so slowly, that it's a real pain to see the users working with it. The filter is a feature for application. E.g. suppose the users are doing address standardization. At first they run the Auto process. This process cleans most of addresses. Then they need to resolve couple of bad records. They have a choice to set a filter to see only the bad ones or work with the whole unfiltered table (the bad records are shown in red)... The implementation of filter is generic and it's build in our framework form class...
>
>I have one application where I still have a huge grid (about 14 columns, 30 visible rows, 30000 records, a bunch of dynamic colors) and ad hoc filtering...
>BUT
>I always filter on the same (logical) field, which is indexed. Since this is a single-user application, and filtering would have to go through the whole table anyway, this way I at least do it in only one pass:
>
set filter to
>blank all field lIsInFilter
>replace all lIsInFilter with eval(cFilterExpr)
>set filter to lIsInFilter
>This way, I still get the usual delay while applying a filter, but after that the navigation is nearly instantaneous, and I know my filter is optimized.

In our case there is a 1 char field, which is a status field. Of course, there is an index on this field. Each user works with his (her) own work file, but there is just one table, which expands status into its description (and there is a relation set from the work table to this 'description' table), and this table is used by all users. If this is the root of the problem, this application can be changed by creating a form's array in Init and then using this array instead of the table...

Currently I'm working on documentation for the old projects of mine. I may play with this idea, when I would be working on this particular project.
If it's not broken, fix it until it is.


My Blog
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform