>>
>>I understand that you came to the conclusion that network problems arise only when a single switch is involved; but with normal functioning of the switch, a user on one switch port should not interfere with a user on another switch port. It therefore ocurred to me that the conclusion reached might be premature, and should be taken with care.
>>
>>A high-capacity switch should not become "overloaded" if two users connect to it at the same time; a bandwidth bottleneck on an individual cable is the only issue I can think of.
>>
>>But let me see whether I can think of other issues.
>>
>>You might try connecting users' network cables to different switch ports - perhaps one of the ports is damaged, configured for a low speed, or with some other special configuration command.
>>
>
>I will bring this to the attention of the customer network engineer.
>
>Thank you very much.
>
>>The switch itself might be seriously damaged. Not very likely, I believe (without the switch stopping completely); I estimate the possibility of individual ports being damaged far more likely.
>>
>>And, of course, I might be missing some other network technology which I know about, or which I don't know about; that's why I suggested checking the configuration - or resetting to factory default (only if nothing special has been configured yet).

Hmm, those switches look like enterprise class devices with a great deal of managed configurability. Very powerful, but lots of chances to make a misconfiguration, too :-/

I'd check the simple stuff - when testing with just one switch, try different patch cables at the router(s), in case there's a bad one. It might not be a bad idea to try different patch cables at the workstations, too - a bad cable there might be just barely OK/in spec for one of the switches, but not for the other. See if you can round up some good Cat6 patch cables for testing. Yet another thing to try would be plugging in one or both of the computers to different wall jacks, in case there's bad wiring somewhere.

Expanding on Hilmar's idea about different ports - try to find out if the ports being tested are on the same network segment, or if the switch has been segmented and you're trying to communicate across segments. If the latter, you may find the traffic is being routed circuitously via some strange path/route on the rest of the network, leading to delays.

It might be worth pointing out to the engineer that VFP apps utilizing VFP data tables require complete, properly configured SMB/CIFS support - think Microsoft enterprise-class networking. If the network supports primarily non-Microsoft networking, the engineer may not be too familiar with what's needed to make a reliable network for VFP.