I do know folks like Erik Moore, John Koziol and others [probable Jim Booth as well] have commented on views, their source tables, and buffering. I think you are just going to have to experiment with this. Normally you let VFP handle the source tables while you just work with [open] the views. When you then get involved with the source tables and buffer them is when problems and unexpected behaviour can occur.

Usually you would not also open a view's source table. You would leave that to VFP. You would also not normally buffer the view's source table.

>Here's the problem - take a table, lets call it entry.dbf, and open it twice, once under its own name and once with an alias - say entrylookup.dbf. Now take a local view that is based on this table called v_entry and open it too. (Mines a parameterized view that only returns one record of the table at any time, but thats not really relevant.)
>
>Go into the view and add a new record or edit an existing record and then issue TABLEUPDATE, the changes are written back without any problems - but which instance of the table did it write back to?
>
>I was expecting record pointer in entry.dbf to be set to the record I had just TABLEUPDATEd in the view and I could not understand why it wasn't moving. Then I discovered that the record pointer in entrylookup was being moved instead.
>
>Whats more its not just a case of moving the record pointer, if you buffer the two tables as well I found the changes were written to entrylookup and not to entry as I expected.
>
>Further experiments indicate that whichever instance of the table is opened last (regardless of whether or not it was the aliased one) was the one the changes were written to.
>
>Needless to say what I want here is to find a way of TABLEUPDATing the view so it writes to entry.dbf and not to my lookup copy that I also happen to have opened at the time.
>
>Has anyone encountered this problem before and/or got a suggested solution?
>
>Many thanks
>
>David