Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Westi on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Advice to Speed up VFP7 Form

Status
Not open for further replies.

JRB-Bldr

Programmer
May 17, 2001
3,281
US
I would appreciate some re-design advice to speed up the display of data on a VFP7 application form running in Windows 2000.

We have a Form which, in addition to a Top Header portion, contains a Pageframe with 10 tab pages.
Each tab page displays data associated with a selected individual and is coming from one or more tables.

Some tab pages display multiple table records unique to an individual via Grids.
And other tab pages display TextBoxes containing individual variable values from the associated table. Currently these TextBoxes are using memory variables as their ControlSource rather than being bound directly to the table field to minimize the risk of erroneous user entry changing data.
* General Data (mostly TextBox displays)
* Order Data (some TextBox, some Grid)
* Monthly Data (mostly Grid)
* Yearly Data (mostly Grid)
* Payment/AR Data (mostly Grid)
* Change Pending Data (mostly Grid)
* General Notes (mostly Grid)
* 3 Other Data Tab Pages... (mostly TextBox)

Most of the Grids are "View for reference ONLY", no direct user input.

As is normal, the users may change the individual they are looking at, thereby causing the form to need to re-acquire data and then re-display it.

One of the initial problems was that after gathering new TextBox data from the data tables and then using ThisForm.Refresh or ThisForm.Pageframe1.ThisTab.Refresh. The re-'paint' of the new data was not working reliably. It was leaving some of the variable TextBox fields showing data from previous individuals or showing blank.
Consequently new code was added to "force" the re-display of each and every TextBox. Unfortunately, as can be expected, this has introduced un-acceptable delays into Form data gathering and displays.
An additional problem is using FILTER's on tables of 200K to 300+K records for Grid displays.
Finally - Older (may be read as slower) user computers aren't being any help to the speed.

I now need to re-think the approach to the entire form to expedite the display of accurate data for an selected individual.

Any new approach suggestions to speed up the data display would be greatly appreciated.

Thanks,
JRB-Bldr
 
1. Textbox Values not updateing.
? What is the ControlSource.Property

2. Check your Page Tabs for code that refreshs them.
Move that code to the activate method.

3. Grids are they seperate tables or SQL statements?
With that many grids I assume they of on the tab pages. Check for code that refreshes them and move it to the tab activate method also.

4. How are the table referenced to each other? Relations? Indexseeks?
I know you said FILTERS and I agree you need to get rid of the ones on large tables.


David W. Grewe Dave
 
Dave;

1. The TextBox.ControlSource are the various associated memory variables. Each independently populated when a new Individual is selected via a GetData method in the Form.

2. I'd like to have the data already acquired prior to the user clicking onto a given Tab page. But the re-paint of the of the Tab Page display could certainly be in the Activate method.

I would need to be cautious of this approach (however very do-able) since I would not want to re-acquire data and re-paint data if the user merely went back and forth into various tab pages without changing the selected individual.

3. The GRID.RecordSourceType = ALIAS and GRID.RecordSource is the table itself, not an SQL Query result.

Since each Tab page grid is displaying data from separate tables and each one individually is not a combination of data from multiple tables, I am not currently using SQL statements to get the displayable records.

4. Those tables which combine data are being used in as RELATED tables. Those tables which do not gain much from being related, are being used separately (not in a RELATION).

As I mentioned above currently the GRID tables are being used with a SET FILTER and then a LOCATE, not typically the fastest approach.

I have wondered if using temporary display tables might be a better choice. Instead of using FILTER on the separate tables, would it be faster to perform a SQL query on the larger table, and then APPEND these specific records to the temporary display table as needed.

Then either create an Index for only those individual's records and exclude the others.
Or do a SET FILTER on this smaller table for GRID display.

Opinions???

Thanks,
JRB-Bldr
 
Pardon me for saying this, without knowing the situation, you are displaying too much information because You think you need to, whether needed or not. Example you have loaded 10 pages and the user may just be passing through i.e. looks at the header portion then skips to the next record. My approach would be No pageframe if possible, if not possible maybe 2 -3 pages at the most, and only display pertinent data. The rest of the data could be opened on a as needed basis via command buttons or a menu in Separate forms for viewing or input.
Parameterized views and Not filters seem like the way to go, But with the Nodataonload flag set to .T. and if and when needed re-queried.
Write a good validation routine and get rid of the variables. Especially the ones where there is no user input. This will also take care of “textboxes showing previous individuals…” Also, I am sure you know, that thisform.refresh only refreshes the active page.
Once done, Run the form in coverage mode, this will identify the bottlenecks
Trust me, I had the very same problem with our first version (VFP3, 100-200 Mgz Machines) , changed it within 6 months and our clients loved the new interface. Forms that took minutes to open and or refresh did it in nano seconds.
 
Pertinent data (main form)
should have general user input
3 other data Tab Pages: if pertinent to every individual and every scenario then in main page.(Even so, I would still cut them up in other forms depending on use)

Financial Form:
Monthly data & Yearly Data: 1 grid with the option to switch to either
Payment / AR
Order Data: ( I assume customer transaction history)

General notes: in its own form
 
First, you're adding a step to the process by using variables instead of buffering. If you buffer the tables, you can edit fields directly with no chance of accidental overwrites.

Second, as others have said, there's no reason to update pages before you show them. That's why the pageframe is designed as it is. If you want to make sure you don't update a page a second time for the same data, you could add a property to each page that set .F. (for all pages) when you move the record pointer and to .T. (for a particular page) when you refresh that page. Then, you can check that property on the way into a page and refresh only if necessary.

Tamar
 
I'd not say that SET FILTER is always slow. That's a matter of how scattered the data matching the filter is.

But give select into cursor a chance, especially for that data you display readonly.

Bye, Olaf.
 
[rant on]
Sorry about my delay in answering, Meetings, I hate 75% of them. Such a waste of time when the other people do not get ready for them.
[rant off]

Looks like you have several good opinions already from other people. I see nothing else to add until you make some of the changes and let us know the results.


David W. Grewe Dave
 
Thanks for all of the suggestions. Keep them coming....

It may take me a while to get the form re-design project elevated in the priorities so my feedback might be a while coming. But when done, I will update this posting with results.

Until then, thanks.
JRB-Bldr
 
Hi. To display a form with lots of tab and grid, I’m using a technique that I found in Foxtalk, a while ago. I’m simulating late binding (excuse my English; it’s not my natural language).

I create a form with one pageframe, 10 pages. On each pages, I have one grid with no recordsource. When the form is shown, in the refresh method of each grid, I open the parameterized view, bind the field for each column, REQUERY() and put a flag to .F. to prevent a re-binding on each refresh.

The trick is that the refresh is issued only when the user click on the tab. So, when he first loads the form, no data load on tab 2 to 10. When he click on tab 5 (for example), the grid is populated, and the data appear.

When he navigates thru the main table, I requery only the grid of the tab displayed. I hope this will help a little.

Nro

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top