Hello Dennis, David, and Cathy!

Thanks for responding.

Here is some more info.

The app doesn't have any FP 2.6 roots so the problem is probably not the same as the one that Dennis experienced.

I agree with David that the records in the UNITS table were not locked individually. David asked about other tables:

Actually the form has three tables on it:

SUITES
**USTART
**UNITS

where the child records USTART and UNITS are in separate business objects. I could update the SUITES record with no problem. (Didn't try changing USTART.)

I will research the suggestion that the record that the form is trying to update is different from the one shown. I recently fixed a bug in this form due to the fact that the current table had shifted from SUITES to UNITS.

There is no grid on the form.

I expected that after sufficient users had logged out that the problem would go away. Indeed this was the case. If this conflict had been impacting the system in more than a minor way I would have had all of the users logout immediately.

It would be nice if the file server could inform us which user was also updating the record.

Of course, the part I don't understand is why anything that another user does using optimistic table buffering would interfere for more than a moment.

Peter