Mike Yearwood has given you some ideas.

I just want to review the SET REFRESH you say you tried....

1) You say you tried 0.5. As I read the Help, only whole seconds are specifiable.

2) The second PARAMETER, which you don't indicate you have tried, controls WRITING of records from the 'client' to the server. It should use the same value as parameter#1, but who knows when the first parameter is not valid???>Hi again.




>
>Many thanks to all who have assisted me so far on this issue!
>
>I've tried all of the measures and suggestions that have been sent in:
>
>- set refresh to 0.5 -> seemed to have no effect on the lag
>- flush -> also had no effect on the lag
>- Set the write back cache on the hard-disk to .f. -> was already disabled
>- =rlock() .. unlock on the table -> had no effect
>
>All these ideas helped me move to a couple of other tests, and I have found that if the timer loop actually opens the database table, checks, and then closes the table ...voila! Now, a submitted request is responded to in the same second!!
>
>
>That seems odd, eh?! Does this provide any ideas as to what I might still be doing wrong? Opening and closing the table every 200 m/secs seems fairly bizarre and strenuous...
>
>However, it IS working at the moment...
>
>Any other thoughts?
>
>TIA Scott :-D
>
>
>>Hi ho, all!
>>
>>I am trying to write a process to fulfil a need my client has... Basically, it involves workstations submitting little jobs to a server process... and the server process ( a VFP7) app will do the jobs.
>>
>>In a test using VFP 7 on a W2K server (766mghz 512 megs of RAM, and EIDE drive & nothing to do :-d)... I wrote a tiny little server test that watches a small jobs table called Test1. It checks the table every 200 m/secs to see if there is a new job to do. Test1.dbf sits on a share that is accessible to the pc's of the lan, but physically exists on the server.
>>
>>Client side: I write a test prg to open the Test1.dbf on the server (via a share), appends a record, rlocks().. fills it out and the immediately unlocks and closes the table.
>>
>>The client and server has sync'd time-clocks, so that I can compare submitted datetime() to completed datetime(). In my perfect world, the client should unlock the record, and 200-300 m/secs later, the server would process that record (that's naive expectation, I know, however..)
>>
>>What I find is that there seems to be a significant lagtime for the server to see the newly created record, obtain its own lock on it and process it.
>>
>>The lag time varies from 2 secs to 5 secs. But not once did the job complete in the same second as it was submitted. In fact, in about 50 tests, the lag time tends to be 3 & 4 seconds ..in more cases than it is 2 seconds...and this server really has *nothing* to do.
>>
>>Now, I know that perhaps some reading this may have already chalked this up to the many layers of W2KServer... but my questions are thus:
>>
>>1. What exactly is the lag?
>>2. Can I decrease the lag via settings/config of the server?
>>3. Can I decrease the lag via hardware improvements? (wide scsi, or beter)
>>4. If there is no tangible ways to improve such a dbf table based approach.. then what
>>suggestions are there of *other* ways to create a centralized job engine where speed of
>>execution (ie; delivery and acknolwledgement of the job) are highly sought after? .. and have it written in VFP?! :-D
>>
>>Any advice on the above would be greatly appreciated.
>>
>>TIA, Scott Barker