>>>>... for all records in the current block only (as far as I know) ...
>>>
>>>What do you mean by "current block"?
>>
>>The cacheblock in the client the record resides in where the RLock() is performed upon.
>>
>>RLock() just forces the server to provide for the most current data for the record, but the server can only throw data at block level. And, it won't throw the whole file obviously. Further, nothing tells the client that it must collect a fresh block when it needs a record when the current block overflows to the next (skip etc.) i.e. the RLock() doesn't provide for that.
>>
>
>Peter,
>Well, from testing I have done, an RLock() performed on any record causes VFP to do one of two things:
>
>1. Recache the entire table.
>2. Set a flag that tells VFP that it needs to refresh the cache on access from this point forward.
>
>If, as you say, the sniffer shows #1 to be false then I suspect that at least #2 is occurring. To refresh a table before reporting, we usually issue an RLOCK(0) (table header) and then run the report. All data displayed in the report is the most current.
>
>SET REFRESH has problems in private datasessions if the table is already open in another datasession (e.g. default datasession).


(note : I guess you read Set Repocess in the other message, which I already changed into Set Refresh; tried it with <s> but doesn't work :( )

Both #1 and #2 can be true when "recache" is seen as just throwing away the cache. Hence #1 and #2 are the same now. I mean, it won't need to reload the entire table, as I suggested earlier. So for that matter, it can easily be true.
RLock(0) I won't know about, but the logic says that that might do the job of throwing away the cache.

The point remains that this is so difficult to test;
The reason why I said "as far as I know", is because I know of different behaviour with respect to this in different environments; nowadays we could try to test this in one PC's two tasks, because all will go through the same client software as if it were a network. However, I'm fairly sure many won't agree with this, and in the end it isn't even true. Just look at the Novell Client parameters, and how much "more" there is according to locking than the Win-client. But, all goes through the registry. Yes, but sure both Win and Novell registry-settings are not the same, and W95 and NT are not the same (for this matter). So what are we looking at ? If Fox says "throw away", will the client-software do that ? yes, (IMHO) it will, when all settings are as "low" as possible (i.e. cache nothing etc.).

Larry, note that when I'm a little right on this, this could only be solved "100 %" by reloading all the blocks in the cache. Explicitly. Or right now, or when the record pointer comes to it. Now I can't proove VFP doesn't do this. But will it ? how to differentiate with already re-loaded blocks ? some flag per block ? won't believe that.

I better stop here, because I could type ages over this subject.
One thing for fun : Set Refresh to 1,1, put a sniffer on a Browse, don't move and look what happens; there is an algorithm out there only Einstein could have invented, or possibly Bill. Anyway, I can't follow it.
Some year ago I could show you completely different behaviour on different PC's (tables on the network). As far as we could see all (registry) settings were equal, but the behaviour was still the same. One PC obeying the Set Refresh, and the other just not (see sniffer). We KNOW this is about caches, but couldn't find the cache.

Going to sniff a beer. Have a nice weekend Larry. Thx.