Hi Tracy,

The Celeron 1.7GHZ w/256mb workstations is probably where the problem lies, they are passable when using TS but not in a LAN setup. These type of workstation are usually built to a price not a recipe, and perform miserably under load testing, i.e. they are full of latency issues and bus bottlenecks.

Just a couple of other points, a DNS Config error can cause problems, a slow DNS can cause performance issues.
i.e. a network running using the router as the switch & DNS rather than the server will be slow, and unreliable, i.e. if the router resets itself for whatever reason it kills the network.
There were a number of LinkSys routers that would reset themselves if you did a trace route.

Check the MTU settings to see if there is packet fragmentation.

Occasionally I come accross a network with TCPIP latency issues, but this takes extensive diagnosis.

Or it could be just a bad NIC.

>Hi Neil,
>
>We have tested with the application residing on the local workstation and on the server with no visible speed difference. I just learned last night as well that most of the workstations are Celeron 1.7GHZ w/256mb ran so that was very dissappointing. There is one P4 512mb system which ran fine. Last night we tested additional memory in the local workstations and a 1GB switch which seems to be the best bet so far. We are researching the most cost effective means to increasing their speed be it memory, switch, additional TS licenses, etc for the local workstations.
>
>Thanks!
>
>
>
>>Hi,
>>TS will always be faster than access via the network, especially if you use SUBST to point to the data, as it takes the redirector out of the equation. i.e. the Database engine has access to the full bus bandwith of the server for access, where as the local workstations have something less than 70Mb/sec/No. Workstations accessing at that time, under high load this can be lower than 5Mb/Sec.
>>
>>Mapping a drive to the dataset on the TS will have measureable performance degradation.
>>
>>UPDATED: A 1Gb link from the Switch to the server does reduce to server bottleneck somewhat.
>>
>>Also where does the exe reside on the client or the server.
>>
>>>We have a location with 7 workstations which use a local lan (100mb) to access VFP tables. The same app and tables are accessed via Terminal Services from a remote location by 8 workstations. The data resides ON the Terminal Server. The workstations connecting through terminal services are fast - there is no delay. However, on the workstations connected locally directly through a switch, there is a delay when stepping through records. It almost appears to be a slow screen draw or something. There is sometimes a 2-3 second delay stepping through the records before the screen draw is done. yet there is no delay at all from the remote site using terminal server even with all users on at the same time. Any ideas? The speed difference appears to be reversed. I think I am forgetting a setting in the Windows 2003 Terminal Server for priority or something??? All workstations at both sites are 100mbs windows xp and a fast switch. The local workstations should be faster than the
>>>terminal server clients or at least not exhibit this strange delay. Pulling records in queries does not appear to be slower though which is why I am wondering about the video/screen refresh issue maybe? The workstations are fairly new windows xp systems.
>>>
>>>I am reviewing this now:
>>>
>>>http://www.msterminalservices.org/articles/Bandwidth-Management-Part1.html