Very cool... Thanks! Your examples cleared-up my confusion regarding when and how to use buffering properties.

>Yup,that's about it- as to why, you'd have to ask MS or some of the real Pros in this forum.
>
>Issuing TABLEUPDATE() on views or tables: same difference.
>
>Buffering comes in 3 flavours:
>
>Not buffered: you write directly to the table, only good with VFP style tables,
>excellent for temporary tables and such. But how to handle a cancel button?
>
>Row buffered: Imagine you have to edit one record in a Customer table. Before you move off the record to some other customer you'd like your user to either save the changes or revert to the original record.
>
>Table buffered: The approach from above will not work if your user has to fill in an invoice with a bunch of line-items. You really don't want to ask them if they'd like to save changes for every invoice line.
>
>
>>Thanks Peter, that sounds like it will work for what I'm doing. A couple followup questions -- is the logic here that you can index a view as long as it's not set to table buffering? Why is that? What is the major difference between table and row buffering when issuing TableUpdate() on views? Thanks again, Renoir
>*Snip