> If user A changes an important field in a record (invoice state for example)
> while user B is editing that same record, alle changes made by user A will
> be overruled when user B updates that record.
> This could cause serious problems, because user A must be sure of the
> results of the update query.
>
> There are several solutions:
> -msaccess will not allow to update a record "changed by another user". That
> works great
> -dbexpress will only put "changed" fields in the update statement, thus
> merging the two changes.
>
> But what is the correct solution for this problem using IBobjects? Is there
> a way to only put "changed" records into the update statement.
> If no, what to do ?
>
> -you could allways use pessimistic lockings, but it will block the system to
> much with more than 30 users
> -you could make the most important fields "read only" preventing IBO to use
> them in an update statement, but that's not 100% safe.

The 6 million dollar question, and the one that only IB/FB
actually gets right! BUT this is not the list to be
discussing it on. ib-support would be better, even if you
are asking about IBObjects!

The bottom line is that this is purely a matter of how YOU
want to use Firebird. Deadlock situations which can occur in
other engines are difficult to achieve in Firebird, and then
usually occur because a user is trying to create the locking
you are looking for :)

If *YOU* want to lock a record then add a flag for it. That
is what I do. Flag it as being edited, and give other users
that information. BUT you then need to have means of
unlocking it if the 'user' forgets ;) and this is where the
knots come.

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. If the record can not now be updated for some
reason, then user B is told of the fact, or else, the
changes user B wishes to make need to be combined with a new
copy of the record after user A commits their change - which
is another conflict I often have.

This is all a matter of your 'business model', Firebird will
actually safely handle anything you want to do!

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