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