>>Hi,
>>
>>I've been having problems with an index getting messed up when issuing a TableUpdate. The problem happens on an ordered table using optimistic row buffering. When there is a conflict I just want to force the last change. The force messes up the index (phantom record.) A Reindex fixes it. The code below will duplicate the problem. (At least with VFP5) Any ideas?
>>
>
>
>Wow, that's a trip. I get the same behavior in VFP6 SP3. I would venture to say that this qualifies as a bug.
>
>My testing shows that this only occurs when you use Row buffering to commit your updates. If you issue an explicit TABLEUPDATE(), it doesn't happen. This fact should get you around the problem.
>
>As an aside, I never, ever use Row buffering because of its unpredictability and inflexibility. I just can't think of a reason that you want to let VFP commit your updates for you without you asking.

Hi,

Thanks for verifying that it wasn't in my mind! Usually I check against OldVal and CurVal and all that, but this time I just wanted to force the change. Even if you do check, and ask the user to verify the overwrite, the same problem happens. It only happens when the table is ordered and row buffering is enabled, the field being changed affects the order, two users are changing the same field at the same time and the different users changes effect the order differently. i.e. Person 1 changes val to "ASomething" Person 2 changes it to "ZSomething" and the table is ordered alphabetically by this field.

Hmmm?

Bill