Thanks. I have done some research and decided to go with a single
Inventory transaction table instead of doing these updates on other tables

--- In firebird-support@yahoogroups.com, "Adam" <s3057043@...> wrote:
>
> --- In firebird-support@yahoogroups.com, "dinol.softedge" <dinol@>
> wrote:
> >
> > Hi Nick
> >
> > Thanks for your response. Why do you say the statement is a recipe for
> > disaster in a multiuser environment?
>
> Because your triggers presume that two or more people can not buy the
> same inventory item at the same time (this may be true, we don't know
> your environment).
>
> To avoid dirty writes, only a single transaction would be able to
> update a single record in TBL_LOC_INV at a time, and no other
> transaction can perform an update on the same table until after the
> first transaction commits, and no contemporary transaction with an
> older view of that record could update it ever.
>
> Now if you update these batch movements at the end of all your user
> activities, then they may occur fast enough to make serialisation with
> retry logic feasible, however if you write this in such a way that you
> update TBL_MOVEMENT_BU from the one transaction over more than a few
> seconds (eg, as each item is scanned at a register), you are in for
> some tears.
>
> Adam
>