Errr, Stephen, you I think you are right.... I did a few simple tests and it seems you _can_ use transaction management without activating buffering.

I looked at the examples in the manual, and to my shame I have to admit that they almost univoqually confirm this. How I inferred that I had to implement buffering is beyond me.

Goes to show ...

Anyway, thank you for drawing my attention to this.

Marc






>>>>
>>>>
>>>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