> set PreparedEdits to false and it will do it.

Automatically.

Bit it will not address the fundamental problem of who is
updating the record in your business model.

------------------
From other message

>>With Generational Records, your first example is handled
>>> properly, by the fact that user A *CAN* change the record,
>>> if user B has not posted uncommitted changes. *WHEN* user B
>>> posts their changes, they will get an error which has to be
>>> handled.
>
> No, user B will not get an error message.
> Changes are just posted, overriding the changes user A made.

Then you have something wrong - it works for me. When user B
takes a copy of the database to edit, it is prior to the
user A post. When the record is updated by user A, then the
'copy' becomes out of date, and a post to that copy 'should'
fail.

> I use IBO, with TIBO-query.
> Just the default settings for transactions (tiCommitted, recVersion :=
> true,using the timer function for committing transactions )

So you may actually be 'refreshing' the copy of the data you
are about to edit as user B? So that they would actually see
the changes made by user A.

We are back to the logic of how you manage the records. If
you need to stop user B now editing the record, the current
state of the record needs to be checked before posting the
change? Something that other engines have problems managing?

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services