>I'm curious how people normally handle soft record locks with buffering? (In case I have my terms wrong, I mean where you put who has the record locked and since when into the record rather than using RLOCK()).
>
>Since the table is buffered, no one else in the system will see the change to the lock status fields unless I do a tableupdate. So when the user wants to edit/add, I change those fields, update the table, and then let them edit. When they cancel or save, I have to change them again and update the table again.
>
>I just get the feeling I'm doing things the hard way. Is this normally done in a better way?
>
>Thanks,
>
>Michelle

Michelle,

To my very personal opinion (!) the whole bunch of "locking" in the area of table buffering stinks;
Looking at your description, you seem to come from RLock() and stuff like that. Well, it doesn't work anymore like that.

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.

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).

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 ...

Any shooting is appreciated from my side.

Peter