Thx Jim .. I'm retry .. and then clarify my results.

Scott

>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