Provides access to members that control Transaction management.
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. |
ITransactions.AbortTransaction Method
Aborts the current transaction.
Public Sub AbortTransaction ( _
)
public void AbortTransaction (
);
Remarks
An application is responsible for stopping only those transactions (using CommitTransactionor AbortTransaction) that were started by the application.
ITransactions.CommitTransaction Method
Commits the current transaction.
Public Sub CommitTransaction ( _
)
public void CommitTransaction (
);
Remarks
An application is responsible for stopping only those transactions (using CommitTransactionor AbortTransaction) that were started by the application.
ITransactions.InTransaction Property
Indicates if there is already a transaction in progress.
Public ReadOnly Property InTransaction As Boolean
public bool InTransaction {get;}
Remarks
ITransactionsdoes not support nested transactions. The InTransactionproperty should be used to test if the workspace is already within a transaction.
ITransactions.StartTransaction Method
Begins a new transaction.
Public Sub StartTransaction ( _
)
public void StartTransaction (
);
Remarks
Applications are responsible for starting a new transaction (using the StartTransactionmethod) on the workspace only if the workspace is not already within a transaction. If the workspace is within an transaction this call will amount to a no operation without error. It should be noted that if CommitTransaction is then called it will be acting on the origin transaction and all changes within that original transaction wil be commited.
Classes that implement ITransactions
Classes | Description |
---|---|
Workspace | Workspace Object. |
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 theITransactions 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).