>>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 ...)
>>
>>What do you do with the parenttable that got updated already ?
>>The problem gets more complicated as more tables need to be update the same >time : as soon as one update fails (for whatever reason) ...

>I think Pascal has it right. Transactions ARE used to rollback a failed
>one-to-many save routine's multiple TABLEUPDATE()s. He's not starting the
>transaction when the user starts editing, he's starting the transaction when
>the user tries to save. Right, Pascal?

Sorry Rich,

I'm actually starting the transaction at the beginning of the editing but I think I'm starting to see the light (it's still a candlelight ...), but with this new point of view (that is starting the transaction at save time as you suggest and not at editing time), I suppose it is possible to run a tabelupdate (or a series of tableupdates) a second time after a first time that failed and was rolled back. What I mean is : if you put the tableupdate(s) within a transaction, can you redo the tableupdate(s) as often as needed until you reach the end transaction ?
Or schematically :

do while lgo_ahead
append, modify, etc
begin transaction
if do_tableupdates()
end transaction
lgo_ahead=.f.
else
rollback
if not user_wants_to_continue_trying()
do_tablereverts()
lgo_ahead=.f.
endif
endif
enddo

Is the the real thing ?