Udostępnij za pośrednictwem

Transactions on Row Objects

  • Artykuł

Every row object exists within the context of an OLE DB session. If the consumer creates a row object directly by using IBindResource::Bind or ICreateRow::CreateRow, an implicit session is created as part of creating the row object. If the row object is obtained from a rowset, it inherits the rowset's session. If the row object is created by executing a command, it inherits the session of the corresponding command object. Finally, if the row object is created from a session object by calling IBindResource::Bind or ICreateRow::CreateRow, it is created in the context of that session.

As a result, to transact row object operations?either column operations or scoped operations?an application creates a transaction as it would in earlier versions of OLE DB, using interfaces on the session, and the application uses the existing interfaces to commit or abort the transaction. For more information about transactions, see Transactions.

As with rowset objects, transactions on row objects can also be initiated by calling ITransactionLocal::StartTransaction. The ITransactionLocal interface is available on the session object. Rows that have been instantiated directly by using IBindResource can use IGetSession::GetSession to get this interface. To commit or abort a transaction, call ITransaction::Commit or ITransaction::Abort as desired. After a row's transaction commits or aborts, the row either retains its full functionality or enters a zombie state. Zombie rows support only IUnknown operations. All other operations on a zombie row return E_UNEXPECTED. The DBPROP_COMMITPRESERVE and DBPROP_ABORTPRESERVE rowset properties also apply to any row objects created from a source rowset. These properties determine whether the row remains active or enters a zombie state, after a transaction is committed or aborted, respectively.

Multiple row objects can participate in a transaction. The following rules govern the semantics:

  • Associated with each row object is a session. Row objects instantiated directly by using IBindResource or ICreateRow all belong to the same implicit session.

  • Row objects instantiated after the call to ITransactionLocal::StartTransaction automatically participate in the transaction in progress.

  • Calling ITransaction::Commit (or ITransaction::Abort) commits (or aborts) all work done on all row objects within the scope of the session.

Note

By default, a provider is in auto-commit mode; that is, any changes are committed automatically. The application can explicitly start a transaction (thus getting out of auto-commit mode) by calling ITransactionLocal::StartTransaction.

The impact of row operations on a transaction in progress is governed by the OLE DB property DBPROP_SUPPORTEDTXNDDL. These properties describe whether data manipulation language (DML) or data definition language (DDL) statements are supported or ignored within a transaction, or whether such statements cause the transaction to be committed. All data manipulation operations on a row object are transacted.

In OLE DB 2.5 and later, the following DML methods are used for updating columns:

  • IRowChange::SetColumns

  • IRowSchemaChange::AddColumns (when columns already exist)

  • IRowSchemaChange::DeleteColumns (because the row-specific columns are not deleted until the row or rowset is released)

The following DDL methods are used for updating schemas:

  • ICreateRow::CreateRow

  • IRowSchemaChange::AddColumns (when columns do not already exist)

In OLE DB 2.5 and later, scoped operations (such as IScopedOperations::Copy, Delete, and Move) are considered neither DML nor DDL.

This topic is a part of: