The BEGIN..END TRANSACTION is, I believe, actually independent of buffering. That is, I think that you don't have to have any buffering set to use it. BEGIN TRANSACTION starts a "record" mode that simply tracks all I/O for any given number of tables that can be "re-wound" by issuing the ROLLBACK command. The buffering working a single table's data. But yes...if you want to be able to "undo" the transactions, then the REPLACE and INSERT commands need to be between the BEGIN and END TRANSACTION statements.

Don't forget to let me know if this seems to solve your problem
//:^)

>One last question.
>
>When the tables are on buffering mode, I always put statements like 'Replace', 'Insert' before Begin Transaction. Is it correct?
>
>Just want to confirm.
>
>Thanks for the answer. I have had some refresh problems on the Novell server and I wonder if LOCK and UNLOCK can solve my problem.
>
>
>>Perhaps something like this...
>>
>>IF !tableupdate(1,.f.,table1)
>> rollback
>>ELSE
>> if !tableupdate(1,.f.,table2)
>> rollback
>> else
>> end transaction
>> =RLOCK(TABLE1)
>> UNLOCK IN (TABLE1)
>> =RLOCK(TABLE2)
>> UNLOCK IN (TABLE2)
>>ENDIF
>>
>>>Where do I put the RLOCK and UNLOCK in this case?
>>>
>>>I usually do:
>>>
>>>[Update Tables]
>>>
>>>Begin Transaction
>>>IF !tableupdate(1,.f.,table1)
>>> rollback
>>>ELSE
>>> if !tableupdate(1,.f.,table2)
>>> rollback
>>> else
>>> end transaction
>>>ENDIF
>>>
>>>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.
>>>>//:^)