Michelle,

As you say, you are NOT from the RLock business. Well, in that case you couldn't understand what I was referring to. So never mind then.

Frankly, now I can't understand your original message anymore.
For me, or for others to help, maybe you can eloborate a bit more ?

About the shooting, this was about shooting at me, not at you ;))

Anyway, you seem to have your problem just because you chose for buffered tables, instead of normal locking. So, if I'm right, you want the locked status to be received by others, which you do by means of some field ?
If I am still right, I was in the right direction indeed, and you solved this (my) problem by means of this. So yes, it's a long way around, and I wonder whether it can be done differently. Actually it can : drop the buffered tables and use normal locking. If you're not using a remote DBMS anyway ...
But I guess you have other reasons for the tablebuffering. :-)

Peter


>To my very personal opinion (!) the whole bunch of "locking" in the area of table buffering stinks;
>
>Well, I prefer it to having multiple users clobber each others' edits.
>
>Looking at your description, you seem to come from RLock() and stuff like that. Well, it doesn't work anymore like that.
>
>No, actually, I've never used RLOCK().

>
>As how I look at it (examined it), your world (of the user) has to change to pressing OK, and finding that the OK wasn't allowed afterwards. I mean, if in the mean time, another has changed the record, you can get that info, and based upon that you aren't allowed to apply the change of the record.
>
>I'm not sure what you're talking about here. If the user clicks on "edit", they are told that they cannot edit this record because another user currently is editing it. At this point, there aren't any changes to apply. And if they really need to edit the record, they can just tell the other user to get out of it.
>
>>If someone hase another idea about this, I am glad to hear it !
>
>>One kind of solution might exist :
>>Have all working with Remote Views, allow all to work with the same physical RV's, and look in there whether records are locked. 1. this is stupid, and 2. I guess it isn't even possible (share RV's).
>
>Why on Earth would I go through all that when I'm working with local VFP data?
>
>It's my guess that if you really want to apply some means of the RLock() from before, you'd have to have a byte for it in the record.
>>And then wait for someone to bail out by a power failure or so ...
>
>No, I don't want to use RLOCK(). I am happy with the soft locking. My question was whether there was an easier way to do it when buffering the data. Some way of bypassing the buffer perhaps.
>
>If a power failure happens, they can just run the clear locks program.
>
>Any shooting is appreciated from my side.
>
>I don't know what this means.
>
>Thanks,
>
>Michelle