Row buffering is the default if you don't change it for the cursor. I agree the situation does seem kind of weird, but opening Customer as read-only might fix it. (This is definately NOT a view, right?) You know that even if you replace a field with the same contents, VFP considers it a dirty buffer. Would you have done anything like that?

Also, when you do get a conflict, you can check GetFldState(-1) to see which fields VFP thinks have changed (the first digit indicates the delete status). Then compare the value in that field to OLDVAL() and CURVAL() to see what's different.

>Barbara,
>
>First off, thanks!
>
>>>3. Both forms have Private Data Session, with Optimistic BufferMode.
>>
>>Using optimistic buffering doesn't tell us if you're using row buffering or table buffering. My guess is that you're using row buffering, but really you should have this table open in read-only mode. It sounds like you're not letting the user make changes to the Customer table from this form, so you definately should open it read-only with no buffering set at all.
>
>Good point, but nowhere in the Invoice form did I put anything that would change the contents of the Customer table, so even if it's in Optimistic Row buffering should it matter? So why does a mere SEEK() on the Customer make an Update Conflict?
>
>Sincerely
>Dennis