I don't know, really, why you have this behaviour. But let me point out that TableUpdate() can return .F. (and, pressumably, has failed!) for a number of reasons, not only update conflict with another user.

This really only affects your message to the user, which might read: "For some reason, the record could not be saved". For a more detailed analysis, use aerror().

>Details:
>-form with private data session
>-free fox2x table
>-buffering: 5
>-add new record does an "append blank" and puts the table in "adding" mode
>-put some data in controls bound to the fields in the table
>-save code
>

>if not tableupdate(0,.t.,thisform.ParentAlias)
>  messagebox('Update conflict! - record locked by another user.',16)
>  set reprocess to (lnSetReprocess)
>  return .f.
>endif

>
>From time to time we get the message "Update conflict...", which leaves the form in "adding" mode, i.e. save and cancel are the only available options for the user.
>If users press Save again, they may get the message a number of times, and in the end it will succed, and the form goes in "view" mode.
>If users press Cancel, a tablerevert(.t.,thisform.ParentAlias) is issued and the form goes in "view" mode.
>
>Every time when "Save" is pressed, a new record, with all changes is added to the table, even though the tableupdate() returns false.
>On "Cancel", one record is still added to the table.
>
>We know that every time when this happens, the index of the table is broken - if we open the table in FPW 2.6, with the order set to some of the tags in the cdx, and issue go bottom, we get "record out of range". For other tags in the cdx, and for no order set, we don't get any error on go bottom.
>
>The table may go for 2-3 moths without any problem, then there are 2-3-4 days in a row when we have to delete all tags and reindex.
>I guess my main question is: how is it possible to get the record added when tableupdate() returns false?
>TIA