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.

Ok. :)

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

I lock the master record with a soft lock so that it can be viewed but not edited while someone else is editing it. I do this by filling in the lckwho and lckwhen fields of the record. The trouble is that since the data is buffered, changing those fields has no effect on the actual table. So the other users won't see that it's locked. To get around this, I change the lock fields before any editing happens, force a table update, and then allow editing. It just seemed overly complicated to me and I was wondering if there was a better way.

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

I don't know why you want people to shoot you, but ok...

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 ?

The problem is that I'm locking the tables _in addition_ to the buffering, not instead of. The buffering has nothing to do with the locking, other than being a hinderance.

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

Glad at least one of us is getting the problem solved.

I don't see the point of dropping the buffering and using RLOCK(). That would make _much_ more work for me than simply forcing the tableupdate. The point of buffering the table is so I can easily revert the changes. Without buffering, I'd have to save a copy of the record before the edit and restore it manually when they canceled. And if I used RLOCK(), I'd have to create a seperate table to store who has the record locked. I'd have to be crazy to make that much more work for myself just to avoid calling TABLEUPDATE() twice. LOL!

Thanks,

Michelle