Steve,

I too wonder about the quality of this example. . .

1) I can't find a SET SQL-type command in the Help
2) The commentary in the code says the set = exempt "overwrites", but assuming they mean the 'overwriting' done by a higher-level transaction's END, then this would be wrong, wouldn't it??

The fine quality of this example matches countless others in the documentation, contributing to novices feeling, all too often, that VFP is just too complicated or doesn't run like it says it will.

Good luck in your quest, by the way,

Jim N

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