--- In firebird-support@yahoogroups.com, "Alan McDonald" <alan@...> wrote:

>
> > --- In firebird-support@yahoogroups.com, "Alan McDonald" <alan@>
> > wrote:
> > >
> > > > Thank you for your answer Alan.
> > > >
> > > > If I understand, what you suggest might work when products are
> > "unique"
> > > > (that is, there is only one of each product), but this is not my
> > case.
> > > > I will give an example.
> > > >
> > > > There are a stock of 100 pieces of product A.
> > > >
> > > > Seller 1 is making an order and he inserts a line which includes 70
> > > > pieces of product A.
> > > >
> > > > Seller 2 is making another order and he tries to insert a line
> > which
> > > > includes 50 pieces of product A. The application should tell him
> > there
> > > > is no enough stock because at that moment there are only 30 pieces
> > > > available (100 - 70).
> > > >
> > >
> > > The same logic would apply with an additional step of counting the
> > un-locked
> > > items, then if there is enough for the order, locking the first N
> > items with
> > > the update statement until the commit unlocks them and marks them
> > sold.
> > > Alan
> > >
> >
> > Hi Alan,
> >
> > Just to be clearer, you mean that Products table would in that case
> > have a column "pieces in Stock" and another "Locked Pieces" that should
> > be updated?
> >
>
> no - in the case of only pure stock counts being maintained, I would use a
> separate table with stockid and -count insertion which is committed at time
> of stock 'grab'
> At time of PO commit, I would update the stock count with the sum of stock
> count and the -count insertion records and delete the -count record
> Alan
>

thx Alan,
I was thinking in the same way as you, but I think that this other way is what Gustavo understood it and why he thought it was an invalid aproach to the problem. So I wanted to make it clearer :)
Best regards,