>I have a View which is opened with table buffering in the data environment of my form. The View has been modified but when I perform a SELECT statement on the contents of the View it does not show the modifications...

Lee, I have encountered the need for a similar data entry situation. Fortunately, I only need to go against a VFP table, not a remote table. What I did (in simplified terms) was to execute an SQL statement that created a real table (i.e, INTO TABLE XXXXX). Before the SQL, I would temporarily turn safety OFF so that the existing table would be quietly overwritten. Then I turned on table buffering (sqlsetprop buffering=5) for that table. Then I let the user do the kind of repetitive editing you mention. I never actually commit those changes to the table (I end up doing a tablerevert on the table and closing it). But before that, I go through the table, comparing eval(field(i)) with oldval(field(i)), and any records with recno()>0 that have had any fields changed are updated back into the master table. I do this explicitly in way that is not transportable to client-server because my records don't have a unique key (a lazy design decision on my part for now). Any records with Recno()<0 are added to the master table with a scatter to array followed by an Insert - SQL from array.

You might be able to implement a hybrid of this situation. Instantiate your view, then Select * from your view into a table as described above. Use that table as your scratchpad, then dump it back into the view. However, I don't know if, with buffering set to 5 for the table, you won't run into the same problem that you initially had with SQL'ing against view.

In fact, I'm really surprised that doing a select on the view itself does not give you the updated values that you have placed into the view (even you have NOT yet done a tableupdate!!). Are you certain about that?