Saturday, 21 February 2004, 9:17 AM

HB> "Really need" means you have a high contention system where different users
HB> are hitting the same rows constantly.

It also comes down to operator expectations. Most operators (in the
area I'm using Firebird/IBObject) would be a little confused and
worried if two of them could be editing a supplier/customer record.

You get questions like, "How do we know we're not changing the same
data?" or "If I can't commit the changes because someone else is, then
why did it let me edit it in the first place?".
They like to see that if they are going to edit a customer record that
they are the only ones who are editing it and that when they do commit
their changes it will work unless something horrid goes wrong with the
database.

HB> Even row-level pess. locking is *not* the coolest way to run a multi-user
HB> system. Better to avoid it and use explicit (start transaction yourself)
HB> ReadCommitted transactions in WAIT mode true, RecVersion False and
HB> hard-commit them explicitly immediately after posting. Handle the rare
HB> version conflict with a good exception handler.

HB> That way, the server will queue the requests.

A question: Is there a way to tell through IBObjects if someone else
is editing a record yet still allow the user to proceed with the edit
using the ReadCommitted method you described above?

Something like that might at least provide a warning to the operators
that someone else may be making changes to the same record.

cheers
Mark

HB> Helen