|Database Tour Documentation|
Transaction (in its simplified meaning) is a set of data changes, which must be completed together. Commit makes the data changes, made in the transaction, permanent, and rollback cancels the data changes.
In Database Tour, transaction control depends on Autocommit option:
1. Transactions may work differently for different database types. See your server documentation for details.
2. The program tries, whenever possible, to create a separate session for each SQL and Table window you open inside a database, and a separate transaction for each database session. This behavior depends on the database type and used database interface. For example, for local BDE database, all child windows are associated with one transaction. For Interbase and most of FireDAC connections, each window holds a separate transaction.
3. The transaction control buttons and menu items are common for all child windows (database sessions) even if the windows are associated with different transactions. Each time you switch to another SQL or Table window, these buttons and menu items will reflect the current state of the corresponding transaction. For example, when the buttons are enabled, then the transaction of the current window (database session) is active (i.e. not committed or rolled back yet).
4. In any floating windows and in DDL operations, initiated through the program GUI (i.e. not from SQL Editor), Autocommit is used.
Transaction isolation level
Transaction isolation level specifies the visibility of changes, if more than one client operates the database:
The following options are applied to ADO connections only (in addition to the previous ones):
You can select an isolation level through Database | Transaction Isolation menu.
Not all levels are allowed for all database types: for example, you may use only the Dirty Read level for local BDE connections (DB, DBF, FoxPro).