>Where do I put the RLOCK and UNLOCK in this case?

RLOCK() can be handled by the BUFFERING itself not unless you have some special cases wherein you will be forced to lock the record. But with the advent of buffering feature most of the Record Locking, Table Locking has been automatically handled.

Just as you have said, the below code is similar to what we are doing except that we added UNLOCK ALL after the process.

[Update Tables]

Begin Transaction
IF !tableupdate(1,.f.,table1)
     rollback
ELSE
    if !tableupdate(1,.f.,table2)
         rollback
    else
        end transaction
ENDIF

UNLOCK ALL

>
>Isn't this the usual approach?
>
>
>>>The solution given by Fred Lauckner on 20/05/98 is very helpful, it's solved my problem and I would like to thank him.
>>>
>>>Now, I have another problem, when two users same the data to the table at the same time, sometime one of it table is not updated.
>>>Is there any different of the below two coding? Because when I used sample (1) to update my data which is enter in grid, the data is gone if the program perform (=tablerevert(.t.)) function.
>>>
>>>(1)=====================
>>>Begin Trans
>>> (update table)
>>> =tableupdate(.t.)
>>>End Trans
>>>
>>>(2)=====================
>>>Begin Trans
>>> (Update table)
>>>Endd Trans
>>>=tableupdate(.t.)
>>>*=======================
>>>
>>>Thank in advance.
>>>
>>>From
>>>Ms Thian
>>After many days of trouble shooting, I found that the only way to guarantee that the data on the server is current is to issue
>>
>>rlock()
>>unlock
>>
>>Immediately after any table updates. For example...
>>=TABLEUPDATE()
>>RLOCK()
>>UNLOCK
>>
>>I am pretty sure that the problem comes from buffering at the server. Issuing the rlock(), apparently forces a write and read of the actual data.
>>
>>Let me know if this helps.
>>//:^)