>>>>>>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?
>>Are you using more than one field to define your primary key? I have not used multiple field primary keys. (Has anyone out there used them successfully?)
>
>Yes, it is a multiple field primary key.
>
>Elyse

It was either a KB article or one of my books that said that VFP has a few problems with multi-field primary key indexes, and advised staying away from them. It appears as if maybe you have stumbled upon one of the peculiar features. Maybe you should consider changing the index to unique?

Erik