Memory variables Vs Table buffering

I learnt foxpro from an old foxbase programmer. I have only used up to VFP6.
Ever since I collect memory variables from my input forms and update the
tables field by field using the memvars. What benefit am I loosing by not
using table buffering other than having to write more code(which I don't
mind!)? How can I use table buffering when I need to do more than one record
in a table (as in accounting entries)?

Stefan
Mon Jan 10 06:07:27 CST 2005


"Muchiri" <Muchiri@discussions.microsoft.com> schrieb im Newsbeitrag
news:AB30F1A3-0459-4AAE-96DC-9962FDCAE249@microsoft.com...
>I learnt foxpro from an old foxbase programmer. I have only used up to VFP6.
> Ever since I collect memory variables from my input forms and update the
> tables field by field using the memvars. What benefit am I loosing by not
> using table buffering other than having to write more code(which I don't
> mind!)?

Right, table buffering helps to avoid (to write and maintain a big lot of)
custom code (as you don't mind :-)
And the built-in buffering is written in C/C++, so it's quicker than custom
xBase code, i.e. the time frame having an uncommitted data state
during TableUpdate() is shorter, i.e. data corruption is less probable.

In VFP variable scope by default does not go beyond the current
method / procedure's life time. So you'd need either to have lots
of Public variables (again more difficult to maintain, as opposed
to the OOP paradigm of encapsulation), unless you use the new
NAME clause of Scatter/Gather to populte object.properties instead
of public vars.

> How can I use table buffering when I need to do more than one record
> in a table (as in accounting entries)?

Use "Table Buffering", 5 or 4, as opposed to "Row Buffering" (3 or 2)


hth
-Stefan