tc> Also, if he's using LOCATE, SUM, SCAN/ENDCAN or a few others I can't
 tc> think of right now, he could be sending huge amounts of data (the entire
 tc> database) across
 tc> the net with each command.
That's not a problem, really, since there is a nominal amount of work going 
on in the workstation with these items. For instance, a reindex, which ought 
to be very similar, causes heavy traffic, but it doesn't generate more than a 
couple hundred packets per second, so other machines can easily get a word 
.
 JD>> Any possibility that FoxPro's runtime thrashes when it gets
 JD>> denied a lock?
 tc> Sure.
A cousin of this may be the problem. There is a pass during the report where 
it
looks like it's unlocking every record in the database. These blast through 
the server like a beer sneeze, and last for about 20 seconds. I could imagine 
a few workstations trying to do this at once drenching the segment. With test 
code, I can slam 2500 packets per second through a server if I do nothing but 
lock and unlock, because the lock calls and responses are extremely fast. As 
soon as I confirm this idiocy in the application, there will be some code 
changes.
Jeff
--- GoldED/2 2.42.G0615
---------------