> In some cases I have some long transactions for several tables, Selects +
> Inserts + Updates !
> One user when send a input to database raise a long business role,

Can you explain what you mean by long business role?

> for example:
> One insert in on table with a date, have to insert a record sum in other
> table or update if yet exist the record in that day ! Image many user doing
> it at the same time !

Not a very clear example. If you are working with commited
information, the everthing should be fine. If you have
several users creating records, then the identification of
those records should use a generator, so that no two users
can 'create' the same record. If these new records are
unique, then the users can not block each other. Updates to
common information should then only be done when the new
information is commited.

> If two or more concurrent user do it, how is the Interbase behavior ? Will
> it freeze ?

With the correct client code then there will be no problem,
but it easy to design sequences of events that will cause
problems. The trick is to update only update shared data
when you need to and probably outside of the transaction
that is inserting it.

> Or What have I to do to improve hard concurrent enviroment ?

Look at why you want to update common data and ask 'do I
need that?' In most cases the answer is no, you want the
results which can be accessed by looking at commited data
rather than modifying values that will affect other users.
It is the sequence of doing things that you need to sort
out, rather than relying on the database to fix a problem in
your program.

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