>Ok for me not to use transactions but how do you handle problems like this :
>


>- tableupdate(parenttable) returns .t.
>- tableupdate(childtable) returns .f. and the user decides to cancel because he doesn't get out (locked record, some ruleexpression return .f., etc ...)

This is OK. You want to start the transaction when you start your save routine. But the user shouldn't decide when to rollback changes, the system should.

What I was advising against is holding a transaction open through a wait state.

The user can decide if he wants to cancel changes before the save routine ever starts. For this, use buffering. for updates that fail because of triggers, locks or whatever, use transactions.