The mode of buffering of the child table is not important. In fact I use a little strange technique - all processing of the child table is made in independent local view (not updateable). When saving, I write child records to the original child table one by one. This table isn't affected while editing as you see. All added child records from both stations are saved anyway - but some of them under wrong parent.

The problem is with the parent table. I have a feeling that one possible explanation is that after the first add request is made from station1, VFP assumes that the record is at the n+1 offset. Second request and the second incarnation of VFP on station2 thinks the same: offset n+1 (It doesn't know that n+1 is "reserved" for station1). After all there is a conflict and offset n+1 stores record1 values. VFP resolving the conflict is lost: returns to station2 the values of record1 as values of record2 and adds an empty record at offset n+2. This fits to problems with a header described by Eric.

The only thing which doesn't fit is: how the station2 can know values of record1 stored in RAM of station1? The only explanation is that the record isn't only in RAM : VFP must write some information to the parent table BEFORE tableupdate.

>You said you are using Optimistic row buffering, I would assume that you are using table buffering on the child table?
>
>I only use Optimistic Table buffering so the problem may lie in the row buffering. If it does then it makes sense that I don't see it since I don't use row buffering.