ITransactions Interface

Provides access to members that control Transaction management.

Product Availability

When To Use

Applications can use transactions to manage direct updates, for example, updates made outside of an edit session, on object and feature classes that are tagged as not requiring an edit session.

Members

	Name	Description
	AbortTransaction	Aborts the current transaction.
	CommitTransaction	Commits the current transaction.
	InTransaction	Indicates if there is already a transaction in progress.
	StartTransaction	Begins a new transaction.

Classes that implement ITransactions

Remarks

ITransactions is an optional interface that allows an application to explicitly control database transactions. The interface does not support nested transactions. The InTransaction property should be used to test if the workspace is already within a transaction. Applications are responsible for starting a new transaction (using the StartTransaction method) on the workspace only if the workspace is not already within a transaction. An application is responsible for stopping only those transactions (using CommitTransaction or AbortTransaction) that were started by the application. If there is an open transaction on the workspace and StartTransaction is called it will amount to a no operation call. With this being said, any calls to CommitTransaction or AbortTransaction will act on the original open transaction.

Applications can use transactions to manage direct updates, for example, updates made outside of an edit session, on object and feature classes that are tagged as not requiring an edit session. This interface should only be used if it is the desire to control the transactional scope while making edits outside of an edit session. For example, it is possible to commit an number of sequential updates to a non-versioned table using the ITransactions interface. When using transactions to manage direct updates, applications are responsible for discarding any cached row objects at transaction boundaries.

Applications should not use transactions when performing updates within an edit session (see the documentation on IWorkspaceEdit for information on edit sessions). In the context of an edit session, transactions are managed by the workspace and automatically started and stopped as needed. 

Applications should be aware that DDL operations made through the geodatabase API (for example, deleting a feature dataset, creating a new feature class or adding a field to a feature class) use database transactions to ensure integrity of the data dictionary tables and commit the transaction at the end of the operation. It is for this reason that the ITransactions interface should also not be used to make any kind of schema edits; this would constitute a nested transaction. Applications should not invoke DDL operations within an application transaction, application transactions should be restricted to DML operations (such as feature edits).

See Also

IWorkspaceEdit Interface | ITransactionsOptions Interface