David:

After trying to digest what you attached I realized that these new conventions of buffering are to make multiuser and client server applications more robust and dependable.

My application I am writing is basically a single user application so I SET EXCLUSIVE ON to make my life easier and everybody is happy with this. So the table buffering is irrelevant for what I do. Since my input screens are real simple perhaps GATHERing and SCATTERing to memory variables referenced on forms would work just fine.

After reading this arcane buffering stuff the question comes up in my mind is if you're writing to MS SQL or Oracle SQL, doesn't the SQL engine take care of all this?

Bruce


>Bruce,
>
>>Another question: how do you put memory variables as GET fields on forms?
>
>Generally in VFP you don't bind controls to memvars. With table buffering you can more easily directly edit table fields and use TableUpdate() to commit changes and TableRevert() to rollback changes.
>
>If you don't want to use a table, you can set up form properties (Form, New Property menu) and bind the control to thisform.YourProperty. This encapsulates the form better than using memvars.
>
>If you don't want to use object properties, just set the ControlSource to m.YourWithinScopeMemvar, but again binding to memvars ala 2.x code doesn't make use of the power of VFP.