My first suspicion would be the anti-virus. Can you disable it temporarily and see if that makes a difference? If it does, maybe you can configure it to ignore VFP data files like dbc, dct, dcx, dbf, fpt, cdx.

As regards Rushmore working for you, the easiest way is to ensure that you have indexes on the important fields - the ones you use to SEEK or in ON and WHERE clauses of Select-SQLs.

good luck


>Thanks Jim
>
>1) 1.8G, 256 RAM
>2) As little as 2 can cause the slower speed.
>3) 100MB network
>4) No
>5) 30,000 records and packed.
>6) how do I check that Rushmore is active?
>7) Trend Micro Client/Server Security Agent.
>
>>Hi George,
>>
>>Some questions...
>>
>>1) What speed of workstation and what amount of RAM on them?
>>
>>2) How many workstations active with the database at any given time (average, max)?
>>
>>3) What speed is the network?
>>
>>4) Does the workstation with the database have other duties like printing?
>>
>>5) What are the sizes of the tables involved?... Any deleted records?
>>
>>6) Are you confident that Rushmore is active?
>>
>>7) Is there anti-virus running on the workstations?
>>
>>good luck
>>
>>>Hi. I have a VFP 5 Order Entry app. that uses optimistic buffering. Works well except when there are multiple users, where saving an order is very slow. A trace shows that it sits on the TABLEUPDATE(.T.) for upto 30 seconds. Any ideas.
>>>
>>>TIA.