Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Performance Advice on Larger Record Sets
Message
From
08/07/2002 09:04:17
Hilmar Zonneveld
Independent Consultant
Cochabamba, Bolivia
 
 
To
08/07/2002 08:01:07
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
00676060
Message ID:
00676082
Views:
15
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.

HTH, Hilmar.

>I’ve been contracted to update and add new features to an existing VFP application. Several months into the process, I’ve been given a new requirement to limit the display of “client” records to the customer’s office where they were entered, but still maintain the over-all record set in a single file to facilitate reporting and statistical analysis for management. The potential size of the table is in the 80,000 to 100,000 record range.
>
>The “clients” table is already tightly integrated with the UI and would be a major task to change, so I’m considering other possible solutions and am looking for advice on performance issues, since I have little previous experience with record sets of that size. The Stonefield Database Toolkit manages the data, so changes in data structure that don’t impact the UI are not difficult (thanks Doug!).
>
>Solution one: add a “location” integer field to the “clients” table and set a filter on it. I’m concerned about performance issues, even with an index on the field.
>
>Solution two: rename the “clients” table to “all-clients” (or some such) and create a parameterized view named “clients” that would then replace the current “clients” table in the DE of all relevant forms. There are a number of indexes that would have to be maintained to support incremental search and grid column header order selection. I have zero experience with views on a record set of that scale and am still concerned about performance and indexing issues.
>
>Can anyone with experience in this area offer advice? Or another possible solution?
Difference in opinions hath cost many millions of lives: for instance, whether flesh be bread, or bread be flesh; whether whistling be a vice or a virtue; whether it be better to kiss a post, or throw it into the fire... (from Gulliver's Travels)
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform