HELP!!!

[venado]

I HAVE AN EXE APPLICATION THAT IS RUNNING IN THE MAIN SERVER(NT) AND IT IS USED BY MANY USERS FROM THEIR LOCAL MACHINES.

I DIND'T INSTALL THE EXE WITH THE DISTRIBUTION DISK USING THE WIZARD, I JUST COPY THE EXE AND THE SUPPORTING FILES TO THE SERVER. THE APPLICATION IS RUNNING ANY HOW.

QUESTION:
DID I DO THE RIGHT THING OR I NEED TO USE THE INSTALLATION WIZARD INSTEAD? I FOUND THE APPLICATION SOMETIME TOO SLOW, WHICH IS NOT TYPICAL OF VFP.

ANY SUGGESTION!!!

 

[GrigoreDolghin]

Hello.

The way you copy the app doesn't work on a client machine with WinNT. IMHO you should build the installation kit and install the app in the client machines.

On the other hand, I really doubt that the app is slow because you don't install it. If it works, it works. If it slow, it's the app.

Just my oppinion.

Maybe a guru will help us...

Hope this helps Grigore Dolghin
Class Software
Bucharest, Romania

 

[fluteplr]

You hit the nail on the head. If it runs the install is ok. The machines probably had the runtimes loaded already from some other VFP install. However on a slow network putting the exe on each client machine can speed up things considerably. Also check what you are doing with temp files so they are not on the server which puts a big strain on network traffic.

 

[venado]

HI AGAIN,

MORE INFO....

I HAVE AN NT SERVER WITH WIN 98 CLIENTS. THE PROGRAMMER BEFORE ME COPIED THE .EXE IN THE SERVER AND CREATE A SHORT-CUT TO EACH OF THE CLIENTS MACHINES. THE APPLICATION IS RUNNING BUT A BIT SLOW. ALL THE .DBF FILES ARE IN THE SERVER AS FREE TABLES, THERE IS NOT A DATABASE CONTAINER. BY THE WAY THE APPLICATION WAS COMPILE TO VFP FROM AN OLD FOXDOS PROJECT.

CAN AN EXPERT TELL ABOUT THIS SETTING. OPINIO AND SUGGESTION.
THANKS

 

[fluteplr]

Again look at where the temp files are being created.

 

[DanWalter]

There are lots of potential bottlenecks with server-run apps. If other apps are running ok from the server, it's probably something in your app. One candidate to look for is table size. Remember, in a server based app, every time you open a table, the WHOLE table gets sucked over the network wire into the workstation's memory. Since this is a legacy app, you might have millions of records lying around! You might be able to archive off some of the data, or re-work the app to use SELECT statements to retrieve just the data needed. Other problem areas could be lots of unnecessary file or record locking, and certainly calls to library files or dll's that really should be resident on the workstation.

As a first step, try copying the app, and all the data, onto a workstation, so you get a stand-alone baseline performance. If it's still slow, you've got the bad code blues. If not, try to figure out where/how the app is slowing down - simultaneous users? retrieving/updating records?

HTH,
Dan Dan Walter
DWalter@zoo.uvm.edu

 

[robinnixon]

Hi venado!

First I warn you, that I'm not going to help you. I only saw something similar in my job.

We have file server (I think there is Linux with Samba) and many Win95/98/2000 clients. Application files (made in VFP5) and tables (about 20 MB) are stored on server. I admit that it makes heavy traffic on network, we know it and it doesn't matter.

My interesting thing is that if I use command SET FILTER TO (SomeExpression) on some big (and of course indexed) table I get result much faster on Celeron 600MHz/64MB RAM/Win98 than on new Duron 900MHz/256MB RAM/Win2000(!). Also on some old slow Pentium2 with small RAM with Win95 works SET FILTER faster.

So that's my story. I don't know why it works on faster PC much slower, I only know it happens...

(My solution in this case was not to use SET FILTER. Instead of that I used SET ORDER TO, SEEK, SCAN WHILE)

Bye, J.