For me and I am sure for many others - using a SQL view for a Browse is often preferable to attempting to replicate that view with a Clarion view. However, if table updates are to occur in a Form from that Browse, there are several issues involved in preparing the table record buffer for update rather than a buffer for the view.
If anyone has worked out these details to an exact science, I would be very interested to learn more or perhaps collaborate on some easy to use class extensions. My guess at this point is that a replacement of the UpdateViewRecord is necessary.
In these cases you don’t use the built in update buttons control template, you need to call the table update independently via a button setting the appropriate setting for update/insert/delete
There is quite a bit of work that the shipping classes & templates do to prepare for a table update. So while embed code may indeed fetch the relevant table record underlying a view record prior to calling the Parent.Ask method with appropriate action, steps such as setting automatic optimistic concurrency & re-getting a view record based on Request/Response after Parent.Ask are also critical.
Because my browse procedures seem to be using server views more & more, I am hoping most of this embed code can instead be done in a few added class methods.