Deferred

Data Manipulation Language (DML) statements are stored in a cache and are not immediately sent to the database. Other users will have no access to that data. Once the transaction ends, Magic xpa updates the database with all of the operations that were logged during the deferred transaction. The updating of the database is performed according to the Identify Modified Row option. All of the DML statements accumulated in the cache are implemented at once, and the transaction is closed. If data for the selected records has been modified before you have committed your changes, an error message will be displayed and your updates will be lost. The only course of action is to redo your updates. There is always a risk that updated data can be lost when working in the Deferred transaction mode.

If a DML statement fails, Magic xpa consolidates and resends the whole transaction.

With deferred transactions, parent and child tasks share the same transaction. If you do a rollback at the child level, the child changes will be rolled back, and so will the changes done in the parent. If you want the child task’s changes to be independent of those made in the parent, use a nested deferred transaction.

Exceptions: Deferred transactions are not supported for local data sources.

See also: SpecialNoCheckIndexInDeferred.

Nested Deferred

An additional deferred transaction is created. When the task ends, the nested deferred transaction is committed followed by the parent deferred transaction. In a parent/child task, changes made to the child tasks are independent of the parent task.

Magic xpa does not work directly with the database to implement nested transactions, but rather the nested functionality is done by Magic xpa itself.

Within Active Transaction

The task is implemented within the active transaction.

• If a physical transaction is opened, the current task will be part of that physical transaction.

• If a deferred transaction is opened, the current task will be part of that deferred transaction.

• If the parent task did not open a transaction, the current task will not be in a transaction.

Refer also to the note below.

Physical

For physical transactions, Magic xpa:

1. Opens the transaction in the database.
   
   Magic xpa allows only one transaction to be active at a time. There is no option for nested transactions.

2. Sends each Data Manipulation command to the database after the Record Suffix level. The exception to this is for explicit locking of Data Manipulation Language (DML) statements, which are sent according to the Locking Strategy.
   
   Magic xpa does not save the commands to a cache like in deferred transactions but, rather, sends each command as it occurs to the database.

3. Sends a COMMIT or ROLLBACK command to the database.
   
   In most database DDL commands, such as CREATE, DROP and ALTER, the opened transaction automatically ends. Immediately after issuing a DDL command, there is an automatic COMMIT performed by the database. You should avoid using DDLs in the middle of a transaction. For example, a table should not be created or dropped in the middle of a transaction.

Platform specific: In ODBC there are no physical locks. When using an ISAM database, see also the ISAM Transactions environment setting.

Refer also to the note below.

Note:

• Creating or updating lots of records without an opened transaction will work in an auto-commit mode, which will result in poor performance.

• If a task is defined with a physical transaction but the task does not have any data sources defined, a physical transaction in the database will not be opened. This means that any subtasks defined with Within Active Transaction will not be part of a transaction and hence might work slowly. In such a scenario, it is advised to verify that there is at least one declared data source from each database participating in the transaction.

Deferred

See description above.

Nested Deferred

See description above.

Within Active Transaction

Acts as a Deferred task.

None

Magic xpa does not open a transaction for the task.

Within active deferred

Default. This transaction mode is equivalent to Deferred transaction mode described above. When executing a task defined with this mode, if a transaction begins (according to the Transaction Begin property), then:

• If a transaction is already opened, then the task will be part of that transaction.

• If a transaction is not opened, then a new deferred transaction will begin.

If the parent task's transaction is rolled back, then the child's transactions will also be rolled back.

This should be used with care, because it is possible for one parent task to have many transactions open in child tasks, all being saved up. Unless there is a good reason to roll back more than one task level at a time, New Deferred is safer.

New deferred

This transaction mode is similar to the nested deferred transaction mode described above. When executing a task defined with this mode, if a transaction begins (according to the Transaction Begin property), then:

• A new deferred transaction will begin.

• Any changes made in this transaction will be committed after the transaction is closed (regardless of the caller transaction).

• The caller transaction can be closed even if this transaction is still open. Closing the caller transaction will not affect this transaction.

• New transactions will have their own transaction cache. The transaction cache will not be shared among them, and any changes made in one transaction will not be seen in the other transactions.

None

Magic xpa does not open a transaction for the task. You should use this on tasks that do not save any data, to prevent accidentally opening a transaction "wrapper" that might bundle transactions in a child tasks. This is especially true if you are creating a main background screen or when creating a background frame.

Note:

A task running in a subform or frame can be set with each of the Rich Client transaction modes defined above.

When using a Call operation with the Destination property set, the task currently running in the subform/frame is closed.

• If the transaction in that task is Within active deferred, then its data will not be committed until the transaction is closed (in the caller task).

• If the transaction in that task is New deferred, then its transaction will be closed and the data will be committed.