>Very good point, Larry, thanks, and I am already firing off a modal screen to edit the contract clauses in an OLEBound field. Unfortunately, the edit-on-request architecture makes the whole requery, update, revert shtick difficult with grandchild tables. The current architecture was the easy way out when I designed the app.
>
>>However, if you can spread that information over several UI interfaces (e.g. pages on pageframes) and requery the appropriate views when needed (like delayed instantiation), it will probably help performance all the way around.

I've done some of this (although not with general fields) with VMP. Once the user edited/added something, they were forced into a non-Default state. When in this state, they had to Cancel out of all their changes or Commit all their changes in order to navigate to the next parent record (in this case, the grid was disabled during edits/adds). This way the Tablereverts()/Tableupdates() code was called in one place and that made it easier for me.

I don't know what your users are looking at now and this may be totally out of synch with what they expect from an interface. Just some thoughts.