>That didn't work. The problem is upon saving the record of the grid, the record pointer isn't moved...

Depending on the parameters, TableUpdate() can try to save only the current record, or all records modified. You can have several pending records, if you set buffering to 5 (= optimistic table buffering) instead of 3 (= optimistic record buffering).

>Thomas, it was defaulted at datasession = 1. I changed it to 2 and some other error messages came up (grid calling the table sort of thing), so it's back to 1. At least for now, to get this program out the door.

A private datasession eliminates conflicts with other forms, that may happen to use the same tables. That way, to Visual FoxPro, each form "looks like" a separate user. Well, almost.

>Seems to my understanding that I may best off with RLOCK and UNLOCK. That way, the record is LOCKed, thus other user can KNOW it is being editing at the same moment. This will then lead me to how to UNLOCK (and SAVE?) after so many minutes, for such "lunch lock". Also, would have to find a way to REFRESH the forms others may be viewing (instead hoping they exit the form and come back again).

LOCK() should usually not be necessary any more, with Visual FoxPro. I use it only in one case (to generate primary keys). In all other cases, I use optimistic buffering (sometimes row-level, sometimes table-level).

For a quick solution, however, you can work in FoxPro compatibility mode, that is, no buffering, no TableUpdate(), no private data sessions. Don't consider this an ideal solution - in the long run, it is much better to master the new commands.

Hilmar.