>>>>>I can easily reproduce this problem without a form.
>>>>>
>>>>>Steps to reproduce error:
>>>>>1) Open table with primary index and set buffering to 5 (Optimistic Table)
>>>>>2) APPEND BLANK
>>>>>3) Go to appended record and fill with valid values (unique key)
>>>>>4) Use up arrow to go to previous record.
>>>>>5) Return to new record.
>>>>>6) Blank out one of the fields that are part of the primary key.
>>>>>7) Re-enter the same value you just removed.
>>>>>8) Go to another record. Wham! Error!
>>>>>
>>>>>Why??? The record seems to be conflicting with itself!
>>>>>
>>>>>Elyse
>>>>
>>>>You should use TABLE BUFFERING... :)
>>>
>>>Robert -- she said that she was..
>>>
>>>Elyse -- that is new to me. is it possible that the new appended record is being treated as part of the table (set when you leave the record) and the edit in 6 & 7 is marking a buffered record (not the one in 2)?
>>
>>I tried to reproduce this and got no errors. Maybe TABLEUPDATE() was fired from some 'obscured' place?
>
>Doing this from the Command Window, there was no way a TABLEUPDATE() could have been fired. I tested this manually, not just from code, and still got the error. And the record count never changed.
>
>Elyse

Elyse, have you tried to track each record with GetFldState(-1) to see how each record behaves in steps 4-7? That might tell you if it's being saved by unknown (as yet) means, or at least what VFP THINKS it's looking at....

HTH
Barbara