>RECCOUNT() ??
>
>Are you saying that something like
>
>a=reccount()
>
>do while reccount() = a
> = sleeper(1)
>enddo
>go bott
>
>will detect faster than
>
>do while .not. found()
> = sleeper(1)
> locate for l_new
>enddo
>
>?
>
>Even if so, my condition test is most often a condition change, not a new record!
>
>Or are you saying that just adding reccount()
>
>do while .not. found()
> = sleeper(1)
> =reccount()
> locate for l_new
>enddo
>
>will speed things up?
>
>With UNLOCK() on the write side, the delay other than the sleep loop now seems tiny anyway , before adding UNLOCK the delay was about 5 seconds, and unrelated to the REFRESH settings.
>
>
>Mike

Mike,

The Unlock (writer) just releases the record to the network, though I encountered situations "today" that even without Unlock this happens while it shouldn't (wrong client settings or so). Thus, this one is completelky logic.

Whether the the DO WHILE RECCOUNT() works I'm not sure, but just an =RECCOUNT() is sufficient to work. Why ? simple (or logic) too :

Whenever an Append is performed, your PC must know about the last record which is contained in the header. So underwater the reccount() is performed. If it didn't, recno()'s would get confused. So, this one is waterproof. Now since you always get the actual reccount(), you *must* get the data too, otherwise things would get inconsistent.

The Lock (reader) always get the actual data too, which is just VPF's kernel. However, this is related to the writer, cause if he did'nt free the record, you will never see it ... When one works decent, this writer's record is locked (untill it's freed) so a lock on the reader's site won't work. But this is just the intention of it all !

When all is left to general VFP, it depends on the Refresh with it's minimum of one sec. Now one sec gives not the best performance, so never rely on that !
We work with 60,60 and can do all we want.
One of the most important things is that once this Refresh-timer elapses, it just refreshes the block coincitently having the record-pointer. So much for your sum on a 1M record table which will never get you all the actual data ! This leads to better set Refresh to 3,600 because just now at least you get consistent data. Nice huh ?

This is just one page of many on this ...

Note : with all client-settings all get rather understandable, also knowing that Fox (FPD) always cached. I mean, on Dos-PC's it already did. Client-settings of today work into that, leaving you (me too) with ununderstandable things. So, shut all cache and locking-features on the client down.

Last one for here :
What works at the dbf-records, doesn't on cdx-records. So there's another world which I understood 10 years ago, but today works differently on Win-machines.
So, where reccount() get's you the actual data always, a Seek still won't find it unless the Refresh-timer has elapsed. Now note that an RLock would do the job again, but you couldn't find the record with Seek ! so what to RLock ??

Anyhow, if the app is decently designed according lock-stuff, you won't have any problems automatically.

Cheers,