>>>I've been reading a lot about this lately, but still don't have a handle on it. When adding a record to a view and then deciding to cancel before saving, what is the best way to get rid of the new record in the view? Delete seems dangerous and I'm not exactly sure how/when to use TableRevert. If TableUpdate commits changes to the base table, does TableRevert only affect the view? If so, if TableUpdate hasn't been issued, does a Requery provide the same thing? Thanks!
>>>
>>>Regards, Renoir
>>
>>Renoir,
>>A view opens with buffering by default and base is nonbuffered. Until a tableupdate on the view itself nothing gets to the base tables. Thus a requery w/o a tableupdate in a way behaves like tablerevert(.t.). OTOH a requery might be time consuming. Think of a view as if it was the base table itself with buffering. If you use tablebuffering, and at a time decide to save 5 out of 8 edited/added records, tablerevert(.f.) for those 3 unwanted then tableupdate(.t.) (or per record for this one too). If you're using rowbuffering than either tablerevert() or requery.
>>Cetin
>
>Cetin,
>
>The issue of the added record is still a problem. After adding a record to a view, then issuing a TableRevert, the field value are reverted, but the record itself still exists in the view. The only way I can remove the added record from the view is by Requery. Is this how it should be or do I have something else going on?
>
>Renoir
>
>Vlad: FYI as your response was basically the same as Cetin's

Renoir,
View default buffering is at rowlevel. Might it be you leave it at rowbuffering, after an add you're moving pointer and thus causing an implicit update ?
Cetin