Hi Scott

I don't have a server handy, so I simulated your scenario by running two instances of VFP.

I made a server program that reports how many records are in the request table (test.dbf)

Test.dbf has only one field [field1 c(10)]


test.prg
USE test.dbf SHARED
SET ESCAPE ON && so we can get out.
SET REFRESH TO 10,10 & just to prove we can do it faster.
LOCAL lnRecs
DO WHILE .t.
lnRecs = RECCOUNT()
a=SECONDS()
DO WHILE .t.

*Without doing any of test 1-4 below
*the update interval is 10 seconds.

*By doing any of the following tests
*you can get much more frequent updates.

*Test 1
*IF RLOCK("1","TEST")
* UNLOCK RECORD 1 IN TEST
*ENDIF

*Test 2
*RLOCK()
*UNLOCK RECORD 1

*Test 3
*USE "c:\documents and settings\all users\documents\test.dbf" SHARED

*Test 4
*This does an implied rlock
*REPLACE FIELD1 WITH FIELD1 IN TEST

IF RECCOUNT()#m.lnRecs
?RECCOUNT(),m.lnRecs,SECONDS()-a
lnRecs = RECCOUNT()
a=SECONDS()
ENDIF
ENDDO
ENDDO


I had the second instance just add records as fast as it could like this...


use test.dbf shared
FOR I = 1 TO 100000
APPEND BLANK
?RECCOUNT()
ENDFOR


HTH

Mike Yearwood


>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