Beginning SQL

International Board Manufacturer has a data entry system that the company uses for entering orders into
its database. Sue takes a call for 100 vt-50 video cards from her client. Checking the Inventory table, she
finds 175 vt-50 cards in stock. Meanwhile, John receives a call from his client who wants to order 130 of
the vt-50 cards. John also checks the stock level and, finding 175 vt-50 cards in stock, assures his client that
there is no problem filling the order. John enters his order for 130 cards in the Order table, and his order
entry program deducts 130 from the 175 shown in the Inventory table, leaving 45 in stock. A few seconds
later, Sue creates a new record in the Order table for 100 vt-50 cards and then updates the Inventory table,
subtracting 100 from the 175 that her copy showed in the table, leaving 75 vt-50 video cards in stock.
The improper use of transactions leaves the database in an inconsistent state. John’s update to the
Inventory table for 130 vt-50 video cards was lost when Sue’s update overwrote the previous update.
Both Sue and John assured their clients that they would receive the product ordered, when in fact there
were not enough video cards in stock to fill both orders. There are orders in the Order table for 230 vt-50
boards, but there are only 175 boards available to fill the two orders. Even worse, the Inventory table
shows 75 boards still in stock after filling these orders!
The Uncommitted Data
Later that same day, John receives an order for 80 vt-100 video cards. Checking stock, John discovers that
there are 95 cards in stock. He enters the order and updates the Inventory table to reflect the order, leaving
15 cards in inventory. As John was entering the order, his customer starts asking about the latest and
greatest vt-150.
Meanwhile, Sue gets a call for 75 of that same vt-100 video card. Looking in the Inventory table, she sees
that there are only 15 cards in stock, so she tells her customer that she will back-order the part and ship
the whole order when the parts are in stock.
John’s client finally makes up his mind and decides to order 45 of the vt-150. John rolls back his order for
the vt-100, leaving the original 95 cards in stock.
In this case, because Sue was able to view uncommitted data from John’s transaction, she has mistakenly
told her client that there was insufficient inventory to fill their order, and she has placed a back order for
even more stock. Had Sue decided to ship the 15 cards, the situation would have been even worse because
John’s subsequent rollback would have set the Inventory record back to 95, when in fact 15 of those cards
had actually been ordered.
The Inconsistent Data
Transactions
John receives an order for 100 vt-150 video cards and starts entering the order. Sue’s customer calls and
asks how many of the vt-150 can be sent to him overnight. Sue executes a query and discovers 135 cards
in stock. Sue’s customer asks about a couple of different cards, keeping Sue busy checking inventory
about different products. John finishes his order for 100 of the cards and commits the order transaction,
leaving 35 cards in stock. Sue’s customer finally decides to just take the available vt-150s. Sue queries the
Inventory table again, only to discover that the quantity in stock has changed from 135 to 35.
In this case, the database is left in a consistent state; no problem was created in the data itself. Sue saw
the actual quantity left; there really are only 35 cards in stock because the rest of the stock was ordered in
a transaction that managed to correctly save its data. She did not place an order for inventory that didn’t
exist, and she didn’t overwrite John’s data.
321