Hi All

If we move from the BDE and TTables, and we "just" replace them with
TIBOTables, are we not "almost" in the same situation with Lock-
Conflicts. Can you not maybe briefly explain/suggests how to best
migrate from TTables & DBGrids to a solid multi-user & highly
concurrent and interactive application. I assume if you still use
DBGrids and other DB-aware controls (even with IBO) that an implicit
transaction is created when a field in the db-grid is changed, and
the user moves to another row in the db-grid. This may cause a Lock
Conflict. If I obtain all my data with a Read Transaction and allow
the user to edit the data in non-db controls, or in a ClientDataSet,
and then when he clicks on Post that I will do the following code:

StartTransaction;
try
SaveEditedData;
Commit;
except
Rollback;
end;

Is there a way that if the exception is caused by a Lock Confict (or
that another user has changed "one" row (or field) of the same data,
that I can handle the problem with the minimum implications - loss of
work). If there is a technique where the offending field/change can
be identified, and that only that field can be "unlocked" so that one
of the two users can finish his save, and that the other user can
then re-fetched the changed data, re-applies his changes, and then
try again to save. We are using FireBird 1.5.2, and somebody said
they used events to notify other users about changes in tables, like
sending an EVENT from within a BEFORE_UPDATE or AFTER_UPDATE trigger.
Ideally I would like to know who is changing a certain field/column
in the database, and if this change cause a Lock Conflict then I
would like to display a message on the involved computers:

"John (Tel Ext: 123) and Peter (Tel Ext: 456) is trying to update the
same field in the database"

If John did a lot of work he can pick up the phone and asks Peter if
he could not maybe Cancel (Rollback) his work. Is this not the ideal
situation, and the best will be, (I don't exactly know how to do
it... (any suggestions)), is to list all the changes about to be
updated in the database, and that Peter can just Unlock the "one"
record that is causing the problem/conflict, so that the loss of work
is minimized.

Thanks