>Let's say that the original value in a field was "abc", then your user modified to "xyz".
>
>

>? myview.myfield && returns 'xyz'
>begin transaction
>     TableUpdate( 2, .F., 'myview' )
>rollback
>? myview.myfield && still returns 'xyz', not 'abc'
>

Oops!! Spoke without thinking it out completely first! The exact problem *is* that the modified value remains the same, because the modified value was derived from teh original.. Now that the "original" has been changed, the value must be recalculated before trying to save again, otherwise you just mess up the data...

Let's say that "xyz" was derived from "abc", let's say that someone updated teh firld before you did, and it is now "pqr", and this causes teh tableupdate to fail, so you therefore Rollback. You now need to recalculate in order to get a new value based off "pqr" rather than off "abc", otherwise you end up with some invalid data. And so we're now back where we started: We seem to need a mechanism to redo those calculations you did in order to modify the field and update with valid data.

---
Jonathan Chan