Hilmar --

Now, another related problem ...

My users select the record they are to edit from clicking on a grid. Previously, they were able to sort the grid by clicking on the column heading. Now, that fails, because apparently its not possible to create an index on a buffered table (I can see the internal problems that would cause).

As for the mechanics -- what you described is what I assumed. I just have trouble understanding why it would make a difference whether its in LOAD or INIT. (If it could have been done it INIT, then it would be possible to pass parameters indicating, for instance, what file to edit.)

Jim



>>Cetin --
>>
>>Ahhh, I was turning on buffering MUCH later ... I'll try it in LOAD.
>>
>>Seems odd that the timing would matter, but I assume that's because I don't understand the mechanics.
>
>Of course, you would have to turn on buffering before the user even starts editing.
>
>As to the "mechanics" - the basic idea is that Visual FoxPro keeps two copies of the record:
>
>1. the value before the user started changing. This can be checked with oldval(...). Also, Visual FoxPro uses this value to check if there is an update conflict, i.e., another user changing the record after you started editing. (The value is compared with the value in the database itself, which can be obtained with curval(...)).
>
>2. The value of the record, changed by the user in memory. This is the value accessed directly, with TableName.FieldName, or through the ControlSource of a TextBox or similar object.
>
>If this sounds a little complicated, there is no reason to worry for now; but just remember to turn buffering on at the beginning, might be in Form.Load(), and don't change it again later.