Causes and Solutions for Deadlocks - SQL Server Query Performance Tuning - page 442

Table 21-1. ( continued )

Entry in Log Description

<frame procname="adhoc" line="2"
stmtstart="44" sqlhandle="0x02000000e3586a2a82
447915dba3de497a09b2eed9643a8 4000000000000000000000
0000000000000000000">
update Purchasing . PurchaseOrderDetail set OrderQty
= @0 where ProductID = @1 and PurchaseOrderID = @2
</frame>

The ad hoc code defined in the listings being run.
You can see the autoparameterization at work on it
again.

<frame procname="adhoc" line="2" stmtstart="38"
sqlhandle="0x02000000178f4e2824eef6
8b5abf0096b085df45a8cbe9d9000000000 0000000000000000
000000000000000">
UPDATE Purchasing.PurchaseOrderDetail
SET OrderQty = 2
WHERE ProductID = 448
AND PurchaseOrderID = 1255 ; </frame>

The definition of the T-SQL.

<inputbuf>
BEGIN TRANSACTION
UPDATE Purchasing.PurchaseOrderDetail
SET OrderQty = 2
WHERE ProductID = 448
AND PurchaseOrderID = 1255 ; </inputbuf>

T-SQL, including the actual values. This would be
the cause of firing the trigger.

</process-list>
<resource-list>
<keylock hobtid="72057594046775296" dbid="9"
objectname="AdventureWorks2008R2.Purchasing.
PurchaseOrderDetail" indexname="1" id="lockf98b8c00"
mode="X" associatedObjectId="72057594046775296">
<owner-list>
<owner id="processf4ecf498" mode="X" />
</owner-list>
<waiter-list>
<waiter id="processf4ced868" mode="U"
requestType="wait" />
</waiter-list>
</keylock>

The objects that caused the conflict. Within this
is the definition of the primary key from the
Purchasing.PurchaseOrderDetail table. You can
see which process from the earlier code owned
which resource. You can also see the information
defining the processes that were waiting. This is
everything you need to discern where the issue
exists.

( continued )