application slows down with multiple users

[poeijer]

I got an application developped in foxpro 7.0

when 1 user works with the application ( opened by a shortcut from the server ) it all works quick.
when a 2nd user opens the application it slows down dramatically. when the 2nd user closes the application it still stays slow, but when the 1st user then restarts his application it is at his normal speed again.

i watched with memory manager on all 3 systems and the memory doesn't seem to be the problem. but it doesnt cause a lot more netwerk traffic with 2 systems..

i hope someone has an idea...

if u need more information just ask...

thanks in advance.

 

[poeijer]

but it doesnt cause a lot more netwerk traffic with 2 systems..


this has to be it DOES cause

..

 

[EzLogic]

Are you running Norton Anti-Virus?
Disable SmartScan in the AutoProtect option!

I had the same problem, and I posted bunch of threads about it here.

I changed Nic, Hub, OS, I re-wrote my Startup codes, and still the same..

Then, I finally found my answer on Microsoft's KnowledgeBase.

http://support.microsoft.com/default.aspx?scid=kb;en-us;321550

Ali Koumaiha
TeknoSoft Inc
Farmington Hills, Michigan

 

[Leland123]

Hi poeijer,

This is from FoxPro ADVISOR TIPS May 2003. The article is titled "Problem with Grid Performance"

***************************************************
It's common knowledge that grids can't use Rushmore Optimization. Therefore, setting a filter on a table that is the RecordSource for a grid can be a bad idea. I recently found out, however, that there's a more insidious problem with filtered grids when they're used in a multi-user environment across a network.

I've had two clients in the past few weeks encounter massive slowdowns, and even lockups, in an application that works with sub-second response times as long as there's only one user connected. As soon as a second user logs into the application, the first slows to a crawl. The second, and all subsequent, users never witness the fast speed. Thanks to VFP's Coverage Profiler, I found that the reason in both cases turned out to be filters on grids. Here are some performance figures from on of the applications. The production application is VFP6, but I was able to test one of them in VFP7, with somewhat improved, but similar results.

One user logged into the application:

Bring up main screen < 1 second
Change to Page2 < 1 second
Enter Edit Mode < 1 second
Save changes < 5 seconds

Two users logged into the application:

Bring up main screen 25 seconds
Change to Page 2 7 seconds
Enter Edit Mode 32 seconds
Save changes 5 minutes

What's worse, the slow times don't even go away after the other users log out and leave only one remaining. It's as if some internal flag gets set in VFP and it can't clear it until you log out of the application completely.

by Andy Kramek, Akron, Ohio
****************************************************

Sugguested Solutions:

1) Use parameterized views instead of using filters.

2) Use SQL selects and direct output to a browse window instead of using filters.

LelandJ

Leland F. Jackson, CPA
Software - Master (TM)

http://www.smvfp.com

Nothing Runs Like the Fox

 

[poeijer]

TeknoSDS: I got a better solution for that. Just exclude the extensions .dbf, .cdx and .fpt. This way you still are protected and it doesn't affect your foxpro application.

Leland123: Thanks, I am gonna test it out some more.

I did find the problem it was some instruction which kinda hung up the system when there were more than 1 users working with it. The strange part is that even when 1 of 2 users logged out the problem still existed. but when the only one left restarted the application the problem was gone. So maybe it could be some queue being still active which wasn't released nicely by Foxpro?

thanks for your helps!