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).

----- Original Message -----
From: Alan McDonald
To: firebird-support@yahoogroups.com
Sent: Monday, August 16, 2010 8:10 PM
Subject: RE: [firebird-support] Read uncommitted



> Hello:
>
> I have an application which is used by several sellers at the same
> time. One seller usually make an order: he inserts a new order, selects
> the customer and then begins inserting lines with product codes and
> quantities. When he finishes, he emits the order. When he inserts a
> line (with product code and quantity), the application tells him if
> there is enough stock. But at the same time, there are many sellers
> doing the same (other orders) and perhaps they select the same
> products. So I would like to verify the stock considering the other
> simultaneous orders.
>
> If I could read uncommitted data form other users, this would be easy,
> but AFAIK, Firebird doesn´t support read_uncommitted in transactions.
>
> I thought of a solution using a temporary table which is filled with
> records while a user inserts lines of an order (with fields like user,
> name of the computer, product code, quantity, etc.). So to verify the
> stock I can check this table. But I think this is a bit dangerous
> because of sudden shut down of computers, etc.
>
> So, my questions are:
>
> Is there any way of reading uncommitted data of another transactions?
>
> If the answer is no, is a good idea to do this the way I thought or
> there is a better way to do this?
>
> Thanks in advance
>

I use transactions to my advantage when I need to do this.
Place a dummy update on a stock item to reserve it.
Other users who attempt this dummy update will be blocked and you can tell
them someone has grabbed the item.
When the order transaction is committed the update is committed and the
stock state is also changed and committed.
If the orderer cancels the order, the dummy update is rolled back and the
stock item is available.
If a PC crashes the update is also rolled back.
Read about dummy updates and the transaction isolation required in the
Firebird book

Alan





__________ Información de NOD32, revisión 5371 (20100816) __________

Este mensaje ha sido analizado con NOD32 antivirus system
http://www.nod32.com


[Non-text portions of this message have been removed]