Foxpro 7 caching/refresh issues during high user traffic 4

[towardus]

Hi,

I have a VFP 7 legacy app which as of last year (a merger occurred increasing our user base about 30%) is starting to show signs of strain. The most alarming problems:
1. Users who save new records to tables or edit existing entries are not being seen by other users accessing those records. Exiting the application sometimes does not help.
2. Tables are not properly synched up. For example if customer.dbf and jobs.dbf are open at the same customerID record on a form that manipulates job information, but also shows information from the customer table, then sometimes the customer information is coming from an entirely different record. The child records in jobs are fine, but the name, organization, etc from customer.dbf are a different customer entirely.

Background info -
These issues are only seen in the summertime (our busy season) during periods when the most users are active in the system - before and after lunch. Our user base is around 40 users, with perhaps 15-20 actively entering and editing job information.
The application's main interface is a tabbed form. For the most part, the controls on the form are getting their data directly from a table open in the form's data environment - with the .ControlSource set to the table's field. There are 30 or so tables open in the DE with BufferModes set to 5.

I have two questions -
1. Does anyone have any suggestions on methods to get more information or narrow down the root causes? My symptoms are not causing errors...

2. If a big change were called for what do you think would yield the highest probability of success:
1. Upgrade to VFP 9
2. Unhooking the data from the interface - getting rid of the ControlSources in favor of pulling down a reecordset into memory variable, manipulating the data, then writing it back to the database.
3. A new buffer/locking strategy
4. Something else?

Thanks for reading this far, and for any light you can shed on this issue.
Dan Pesta

 

[Dan Freeman]

That user load is really quite light. Something is badly wrong in the application for a parent record to be mismatched.

If you really are using buffering through the DE, then you already have #2 in place. Note that with buffering, changes made on one workstation will not be seen on other workstations until the changes are committed and then the buffer is refreshed on the other workstations.

None of your proposed changes will inherently help solve the problem of a misplaced record pointer. (Well, OK, #4 may help. <g>)

 

[JRB-Bldr]

You might also make note of whether or not the users are having 'slow downs' with other network operations such as opening or saving WORD or EXCEL documents which are stored on the central server(s).

I have seen network bottlenecks become significantly more dramatic when the number of users increase.

If network bottlenecks were an issue, it could be a contributing factor.

As DanFreeman has indicated above the issue is most likely not in VFP7. Instead it may be in the design of the application and how it accesses/displays the data. If that same design were merely migrated to VFP9, the problems would persist.

If you find application design problems these could be resolved within the VFP7 application or, with a little more effort, the 'fixed' design could be migrated to VFP9.

Things like: "the name, organization, etc from customer.dbf are a different customer entirely." sound like table Index or Index utilization problems. If the indicies are working as intended and your user interface utilizes the indicies properly to establish table relations, then this should not occur.

Issues like: "save new records to tables or edit existing entries are not being seen by other users accessing those records" could have to do with refreshes of the grid data within the individual user interfaces - most especially if the displayed data is buffered.

Good Luck,
JRB-Bldr

 

[Imaginecorp]

As has already been pointed out, switching to VFP9 with the current design will not help... Seems like a design flaw, 40 - 100 users is nothing nor 30 tables in the DE.
Depending on how important this app is you may want to consider redoing it.

Regarding customer info coming from a differnt record, check if your forms are in Private Data Session as opposed to Public. If Public you may see this behavour as the customer record pointer could have been moved by another user

 

[craigber]

Make sure write caching is turned off at the server.

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com/blog

 

[towardus]

Thanks to all of you who have given advice over this issue. The server is currently write-caching, and it's probably going to be a battle to make that change, but more importantly, you have helped me put the focus where it will do the most good - on the code and the design of the program. I did find and fix a few things over the weekend, and we'll see what effect it has moving forward. Thanks again for taking the time to offer your advice.
Dan

 

[Imaginecorp]

Glad to be of help...