Thsnks for the reply, I found the problem. There was a piece of code I wasn't aware of that was using record number to reposition the XLH record, and that record number was not being reset when someone else got in ahead and saved a record first. In other words, the data entry form was APPENDING BLANK and saving then new record number, say 123, but before the UPDATEBUFFER command, someone else saved a record in position 123, so the saved record number of 123 was no longer the record number of the appended blank record, but the form was repositioning on 123 before UPDATEBUFFERS.



>I have a client that has had intermittent problems with an APPEND BLANK overwriting/reusing a record already on file. I think I have it fixed and I have them testing it, but I wanted to describe what I've done to see if it the fix sounds right.
>
>Right now, in the live system, records are added to XLH.DBF file 2 ways, one form adds them as INSERT INTO XLH (flds) VALUES (Values), and that form has buffering off. Only one record is added at a time. The second way XLH records are added is on another form that adss via APPEND BLANK when the user hits the Add button, and that is also one record at a time. That form has XLH buffering set to pessimistic row.
>
>What has happened about 10 times now is that if the APPEND BLANK happens close to the time of the INSERT in the other form, instead of getting a blank record the user is positioned on the record INSERTED from the other form.
>
>I have installed changes in the test system so that all forms that can add XLH use the same buffering scheme, Pessimistic row, and of course I am having them test by trying to add records at the same time in both forms.
>
>Does this sound like the right approach, or am I missing something?
>
>Thanks