Completing prepared transactions

WARNING! Heuristically completing a prepared transaction can cause inconsistent results for an entire distributed transaction. The System Administrator’s decision to heuristically commit or roll back a transaction may contradict the decision made by the coordinating Adaptive Server or transaction protocol.

Before heuristically completing a transaction, the System Administrator should make every effort to determine whether the coordinating Adaptive Server or transaction protocol decided to commit or roll back the distributed transaction (see “Determining the commit status for Adaptive Server transactions”).

By using dbcc complete_xact, the System Administrator forces Adaptive Server to commit or roll back a branch of a distributed transaction. After heuristically completing a prepared transaction, Adaptive Server records the transaction’s commit status in master.dbo.systransactions so that the transaction’s coordinator—Adaptive Server, MSDTC, or an X/Open XA transaction manager—can know whether the transaction was committed or rolled back.

Adaptive Server propagates the command to heuristically commit or abort a transaction to any participant servers that it coordinated for the transaction branch. For example, if in Figure 3-1 you heuristically commit the transaction on ASE2, ASE2 propagates the command to ASE4 so that the transaction on ASE4 also commits.

dbcc complete_xact requires that you supply an active transaction name and desired outcome for the transaction. For example, the following command heuristically commits a transaction:

dbcc complete_xact "00000b1700040000dd6821390001-aa01f04ebb9a-00000b1700040000dd6821390001-aa01f04ebb9a-caserv1-caserv1-0002", "commit"