> Really, is there a way to allow multi-users update same record,
> on a kind of "queue" without locking?

Not really. Interbase does not have ESP, it has no way of determining
which updates are safe to queue and which should cause conflicts.

You can setup pessimistic locking (IBO performs a dummy updated when
you started editing). Locking does not queue the updates, it just
locks the record so the other user can see the record is not available
before they start - instead of when they try to save all that work.
This will not protect you from trigger side-effect during inserts
(such that you described).

Generally speaking you should try to design your database structure to
minimise the side effects of triggers on user interactive tables - or
understand and accept the consequences. There are various ways of
working around such issues, but it largely depends on the
requirements.

In your example you may setup a partial batch system. Insert records
into your own table/queue of articles ordered. Any query you do for
availability must adjust the articles count according to the records
found in your separate queue. Then, once a day or whatever, you run a
procedure which adjusts the main record and deletes the queue records.

Notice that this will NOT protect you from over-ordering. In the
situation of two users altering acting simulateously they will both be
looking at an old article count value (they cannot see each others
uncommited changes) and so will be permitted to save their orders -
even if this takes the orders over the available number of articles.
Your only protection from overordering in this situation is to lock
out the second user at some point - which IB was kindly doing for you
:-)


Geoff Worboys
Telesis Computing