>>>
>>>
>>Marc,
>>
>>I agree that you need the dbc, which is there and I have a transaction class that is handling that job. Like you, it does a rollback if an error occurs. I've found it to work without buffering on the tables though. I can only say that I know this because if an error happens, the updates do not take place. I have not done rigorous testing of it.
>>
>>Steve
>
>Steve,
>
>That is interesting. But I'm not sure you are right, because I do not need buffering for my purposes at all, since like you my users do not modify the database directly. Where you use properties, I use a cursor, but I think that does not change a lot. Since I do a lot of one to many input with grids, it seemed more natural to me to use cursors.
>
>It may me a weird argument but at the time I conceived my system, I would not have installed buffering if I did not need it, and I guess I did because of my reliance on transaction management.
>
>Kind regards,
>
>Marc

This is an example of transaction usage apparently without buffering from the help section for VFP 6.0. Although many references are made to the use of buffering and =TableUpdate, this example indicates to me that it may not be necessary. But then again, this is M$ documentation and who knows. But, I have noted when crashes occur while developing, the data is not saved to disk.
***********************
Notice in the following example that because changes in a nested transaction aren't written to disk but to the transaction buffer, the inner transaction will overwrite the changes made to the same STATUS fields in the earlier transaction:

BEGIN TRANSACTION && transaction 1
UPDATE EMPLOYEE ; && first change
SET STATUS = "Contract" ;
WHERE EMPID BETWEEN 9001 AND 10000
BEGIN TRANSACTION && transaction 2
UPDATE EMPLOYEE ;
SET STATUS = "Exempt" ;
WHERE HIREDATE > {^1998-01-01} && overwrites
END TRANSACTION && transaction 2
END TRANSACTION && transaction 1

Thanks,
Steve