>I think you're misunderstanding the situation. The user has made changes (perhaps quite a few) to a child table (a view) that is displayed in a grid. They then attempt to save the record and during the save it says that they can't save because "the cursor cannot be modified because it contains uncommitted changes." Well, yes, it does contain uncommitted changes. All of which need to be saved, but instead I get this error. I can't TABLEREVERT because the user has made changes with the intention of saving them, not reverting them. It's like saying "sorry, you've made changes therefore I can't save your changes - you'll have to revert your changes, make them again, and then maybe I'll be able to save them next time."
>

Hi Russell,

I am afraid you misunderstood the error message "the cursor cannot be modified because it contains uncommitted changes.", it has nothing to do with presence of changes waiting for the TABLEUPDATE. And the workaround "make sure the record is saved" has nothing to do with executing TABLEUPDATE.

I replied to your message just because you stated the following:
>
saving prior to inserting records. Well, that's not workable. I need to be able to give my users the ability to save or cancel a tranaction as a whole and this "workaround" prevents that.
>

And I don't see how the workaround would prevent you from "be able to give my users the ability to save or cancel a transaction as a whole ". If you are using table buffering, the workaround will not prevent you from that. Even if you save the record, it'll go into the table buffer. If later you want to send it to the back-end along with some other changes, fine, execute TABLEUPDATE(). If later you want to cancel the modification, execute TABLEREVERT(). There is an ability to save or cancel the transaction as a whole.

Thanks,
Aleksey.