>The problems with the default tableupdate() as called from buttonset.updatetables is what I am trying to solve. The requirements for update are far beyond what VFP gives by default, in such a complex view. The view itself is made from three other views,plus tables so I know there is no choice, if I stay with the view, but write my own Update/insert funcs. What I was realy hoping for was a way to avoid the view in the first place. Unfortunatley, loading 10,000 records just to update one is not satisfactory, and thus far the view is the only work around I have found. Only two child tables from the view load more records than they should. Basicly though, if I was to call SCATTER MEMVAR in buttonset.updatetables, would I get the updated fields? If so, it would not be too hard to write the update. I checked, and can bail out of the assorted row level triggeres by comparing :old.Value to :New.Value which solves the !update if ! dirty problem

If all you need is a read-write cursor to make changes to, you can do this by just using a SQL select, and then opening the base table again in another work area.

USE DBF("SQLResults") AGAIN IN 0 ALIAS RWCursor
Then make changes to that. You can then set buffering on in that copy of the table and use CURVAL and OLDVAL to build your sql select. You're going to have to build your update statement manually whichever way you look at it, because of your special requirements.

This gets you out of the view. But you lose some stuff going to a cursor that might have been helpful with a view. With a view you could have used DBGETPROP("MyView","Field", "UpdateName") to find out a field's base table to help you in building your update statement.