Про полезность фичи, никто не спорит. Но как-то отрыв inventTrans от inventSettlement несколько смущает.В прочем на фоне того что натворили в DAX2012, это не самая большая проблема совместимости.
Эскалация блокировок (если верить
MSDN), случается если "A single Transact-SQL statement acquires at least 5,000 locks on a single nonpartitioned table or index."
Теперь представь картину:
1. У нас есть 10 групп складской аналитики
2. По каждой группе система одним update'ом помечает нефинансовые переносы закрытыми. Есть большие шансы что часть этих updateов будет обновлять более 5000 записей и блокировки будут эскалированы до уровня страниц.
3. Я, конечно, не до самого конца понимаю, как как эскалация блокировок работает, но рискну предположить что по кластерному индексу окажутся заблокированы записи с соседними inventTransId, которые (вполне возможно) не имеют отношения к текущему закрытию и вообще еще в статусе Ordered/onOrder.
4. Как результат, либо закрытие будет ждать пользователей, которые заблокировали записи, не имеющие отношения к закрытию, либо наоборот - пользователи будут ждать закрытия.
5. Поскольку блокировки будут создаваться не все сразу, в порциями по одному созданию (и ожиданию) блокировок на одну группу складских аналитик, шансы на создание дидлока или, по крайней мере, дерева блокировок, резко возрастают.
То есть - идея состоит не в том чтобы от механизма отказаться, в просто в том чтобы постараться не генерировать update-statement, которые обновляют слишком много складских проводок в одной операции...