Dear Michiel,
I read your story with great sympathy.

>>>We change the record which is RLOCK()ed with the other user. It just works.
>>>Now the question. How do we get a error message with TABLEUPDATE() that the record is locked and can't be changed?
>
>Well I now understand that nothing can be changed when there is a RLOCK on it. That's okay. But I would like to let the user know that the record can't be changed because there is a lock on it. But strange enough it doesn't work. Look at what we have to check the error of TABLEUPDATE(.T.):
>
>IF TABLEUPDATE(.T.) = .F.

I have found the MicroSoft code isn't very good. I haven't had your problem, but be thankful you haven't had this happen to you: One client reported months of problems where, suddenly, every record would become locked. This started when they installed an MS Server code, and continued thru a series, even NT Server. I found resources in the server, when that work station had locked off. The users reported they would all log off, that would clear the problem. I have more grief than you want to hear, different strange occurances, but here's how I finally fixed the problem: I would close and reopen the DBF after every unlock. That fixed it. Apparently, MicroSoft takes a CLOSE FILE seriously, but is willing to drop a mere UNLOCK packet whenever. Naturally, nothing has ever gone wrong in years of NOVELL and LANTASTIC sites. Forget the "CONTAINER OBJECT"
-Gary Nemeth, Hampton Corporation, since 1983, Fox since 1988.