I have run into similar timing issues and found that issuing an RLOCK() solves most problems. Doing so virutally guarantees that I am looking at up-to-date info. For example...
USE table1 SHARED
*On some event timer call MyFunction()
PROC MyFunction
**Check for some status/updated record
*Issue RLOCK to force table1 refresh
=RLOCK('table1')
UNLOCK IN table1
* Do whatever you need...
RETURN
HTH
Larry Long
>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
