This is a known effect having to do with opportunisitc locking. It means that the workstation chaches a lot of data on the workstation (having read and write buffers). When a second workstation logs in, those buffers needs to be flushed and each and every read and write need to go directly to the server. This obviously takes more time.

So this is not a bug, but an optimizing feature for one workstation.

Before listening to the other arguments (which are valid hint but often shots in the dark IMO), please read the following.

It indicates that you network traffic is not optimized. You can use a tool called filemon (www.sysinternals.com) to see what network traffic you application is generating. By analyzing the log generated (tip you can filter on traffic generated by your application exclusively), you can start identifying the performance problems. For example it mightbe that a SQL statement is dragging the whole table accross the network. Then you will see a large chuncks of data being read from a particular table.

Please take some time to learn this tool and it will reward you in being able to identify each and every network performance problem.

Walter,

>This database is also built with SDT and Mere Mortals Framework and is physically on a Windows 2003 Server. When one workstation logs into the database, latency is not an issue. As soon as a second workstation logs into the database the speed and response of the application is reduced drastically. Even after the second workstation logs out of the database, the first workstation still experiences latency issues until that workstation logs out of the database and logs back in. Then speed picks back up to normal. Only one workstation can work in the database at a time without any big-time delays.
>
>Any help would be much appreciated. Let me know if you need any more info.