Hi Al

And installing VFP on the server wouldn't help performance anyways. The server isn't running VFP at all!

>>First of all, many thanks for replying.
>>
>>Yes, I have temp files (working, sorting, etc) set to local disk in CONFIG.FPW. As a matter of fact, I'm rewriting an application from FP 2.6 (DOS version) to VFP 6.0. Old application (.EXE) in FP 2.6 on users' local drives accessing tables on very old server (about 8+ years old) still works very well - faster than VFP 6.0 on brand new server. Strange. Now you see why the users are complaining, they'd rather stay on the old system.
>>
>>As for AV, I don't think I can uninstall or I'd be in trouble! ;-) I just disabled it and tested it. Furthermore, I don't have access to the server physically, only via Terminal Client. According to the postings, the problematic AV appears to be only Norton, nothing was mentioned about McAfee...
>>
>>A guy over in Network Admin said I need to install VFP 6.0 on the new server. Should I do that? I've never installed FP 2.6 on the old server so I didn't think it would be necessary, eh...?
>>
>>I don't understand what you mean by "is the disk pounded hard?" Nor do I understand "Is there a jabbering network card flooding the network with bad pockets?"... as for network performance of other (non-VFP) apps, the new server is exclusively used for VFP database/tables, nothing else. As aforementioned, old application in FP 2.6 with tables on old server works well over the network - that is, in the same network architecture... :-\
>
>First of all, let's be clear... you're running a conventional VFP app on a LAN, that is, the data files are stored on the Dell server, and the app is actually running on the workstation(s)'s CPU(s). You're not running the app on the Dell server through Terminal Server.
>
>Mike's idea of replacing the UNC file names with mapped drive letters worth trying but my understanding is VFP is supposed to work fine with UNCs.
>
>In another message you said that the old FP2.6 app is fast, working against a different server. Are you testing with the same workstations you're using to test the VFP app?
>
>When you're testing the VFP app, make sure you have the ones you're not using switched off, and preferably disconnected from the network (some PCs have "wake on LAN" features, so the network card is alive even though the main PC is switched off). That way, if you have a bad network card or some sort of problem with one machine causing network contention, that will help isolate it. For example, if you have 3 workstations A, B, and C:
>
>Leave C switched off. Test first with machine A, then add B and see if B is slow.
>Leave B switched off. Test first with A, then add C.
>And so on.
>
>Are there any networking differences between the "fast" FP2.6 app and the "slow" VFP app? For example are the servers attached to the network through different hubs or switches?
>
>Get your network admin to look at:
>- the server event log to see if there are any error messages/conditions that could shed light on this
>- check running processes/apps/services for anything unusual. For example is there any unusual real-time backup software operating?
>- the server Performance Monitor, and review some basic parameters like CPU utilization, disk usage statistics, etc. There are lots of tools available to help pinpoint where a bottleneck may occur.
>
>Finally, if you're running VFP on the workstations you're right, there is no need to install it on the server.