Query in one step

Question

I have available quantity of some product on my stock in different warehouses.
Now, i have to take some quantity from stock.
I have to take it from warehouse based on priority order.
Every product has some packing unit, for example 10 pieces in one package.
If there is quantity less than packing unit in some warehouse i have to take it on the end.
I should not take all quantity from one warehouse but 10% from every warehouse until I take all required quantity.
I think that the following example is clear enough.
Can someone create a query in one step? Or at least with the less possible steps. I have tried with recursion but with no success so far. If possible without cursor.
CREATE TABLE #test(whId INT, availQ INT, priority tinyint)
INSERT INTO #test(whId, availQ, priority) VALUES
(1, 100, 1),(2, 5, 1),(3, 40, 2),(4, 30, 2),(5, 60, 2),(6, 20, 3),(7,10,3)
--I need to take quantity=250, 10% on each step, order by priority and quantity
--taking by packing unit=10, if doesn't exist enywhere more than packing unit than take what exists
--step 1: priority 1(first take from the highest priority warehouse): 10%=33, qRemain=qRequired=250
UPDATE #test SET availQ=67 WHERE whId=1
--(whId=2 has quantity less than packing unti, so leave it untill the end)
--step 2, stil priority 1, qRemain=250-33=217:
UPDATE #test SET availQ=34 WHERE whId=1
--step 3: stil priority 1, qRemain=217-33=184:
UPDATE #test SET availQ=1 WHERE whId=1
--step 4: stil priority 1, qRemain=184-33=151:
--now there doesn't exist record with quantity greater than packing unit and priority 1, so take what is left(order by quantity):
UPDATE #test SET availQ=0 WHERE whId=2
UPDATE #test SET availQ=0 WHERE whId=1
--step 5: go to priority 2(since priority 1 is already all used), qRemain=151-1-5=145:
UPDATE #test SET availQ=27 WHERE whId=5
UPDATE #test SET availQ=7 WHERE whId=3
--step 6: still priority 2(no row with availQ>qPack), qRemain=145-33-33=79:
UPDATE #test SET availQ=0 WHERE whId=4
UPDATE #test SET availQ=0 WHERE whId=5
UPDATE #test SET availQ=0 WHERE whId=3
--step 7: go to priority 3, qRemain=79-30-27-7=15
--priority 3 are two warehouses with availQ lower than packing unit, so, take the row with greater Q:
UPDATE #test SET availQ=5 WHERE whId=6
DELETE FROM #test WHERE availQ=0
--at the end I have in my stock available quantity=5 on warehouse id =6 and 10 on warehouse id=7
SELECT * FROM #test
DROP TABLE #test

Answer 1

I have difficulties to understand some of the basics of the problem. How can 10% of 250 be 33?
I seems to me that you at first should check if the total for the current priority is less than required quantity, and this case you can empty all these warehouses in one go.
It's difficult to say whether this can be done in a single statement and in that case whether it should be done. It seems that the windows function in SQL 2012 could come in handy. Without them, it may be faster with a cursor.
A recursive query may be possible. However, for a query like this it may be a cursor in disguise and not particular faster, only more difficult to understand and maintain.
But if you need to do this for multiple products at one occasion, it is definitely feasible to do this with set-based iteration and allocate warehouses for all products in breadth.
Since you discuss read-committed snapshot: with a single query you would see the same data all the way through the query, as long as you don't use scalar-defined functions with data access. If you are really dependent on the data not changing, you should
use true snapshot isolation. But that assumes that you want to perform your computations on the fixed state when the operation starts, and I am not sure that is what you want. Let's say that in your example that when you start the operation that there
10 units in warehouse 7, but before you come to check that warehouse someone else takes those 10 units (or for that matter deposits 50 new units).
Let's study the possibilities here:
1) True snapsnot: you would read 10 for warehouse 7, but when you try to update, you get an update conflict and the operation fails.
2) Read-committed snapshot, using a single query: You would read 10 for warehouse 7, take those units and then set the quantity for the warehouse to -10. (Or even worse, set it to 0, having taken 10 units that does not exist).
3) Read-commited without snapshot: when the query reaches warehouse 7, it would read 0, and ignore the warehouse. Or you would read 10 and when you come back to update, the 10 are gone.
4) You run the transaction with REPEATABLE READ: Someone may steal those 10 units in wh7 before you get there, but that's alright. But once you have read them, they are yours - unless someone else also read them, but have not yet updated the quantity. In
this case, you will get a deadlock.
5) You use the hint UPDLOCK when you read the data. This the same as REPEATABLE READ, however other processes cannot take out an UPDLOCK on the row. (They can read the row with a shared lock.) This prevents deadlocks.
Here I assuming that you first assmeble what to take from the warehouses in a temp table and then update the warehouses as well your picking-lists. If you update directly and use the OUTPUT clause to get the data for the picking-lists, this alter the equation
somewhat: UPDATE should take out an UPDATE lock for you. But the situations still requires careful analysis, and particularly you need to take care that you don't use the snapshot when you shouldn't.
Erland Sommarskog, SQL Server MVP, [email protected]