See Also: Get_Attribute, Set_Attribute
Indicates the type of transaction processing for the table.
Table
All Drivers
Enumeration list, permanent
Read / Write
DF_FILE_TRANSACTION_NONE, DF_FILE_TRANSACTION_CLIENT_ATOMIC, DF_FILE_TRANSACTION_SERVER_LOGGED
DF_FILE_TRANSACTION_SERVER_ATOMIC (obsolete)
DF_FILE_TRANSACTION_NONE indicates this table is not eligible for transaction processing. DF_FILE_TRANSACTION_CLIENT_ATOMIC, DF_FILE_TRANSACTION_SERVER_ATOMIC, and DF_FILE_TRANSACTION_SERVER_LOGGED indicate the level of transaction processing that will be applied to the table. The availability and functionality of these levels are driver dependent.
Client-atomic transactions can be aborted by the program and, under some circumstances (e.g., deadlock) they will be aborted automatically by DataFlex. Client-atomic transactions do not provide protection from workstation crashes. If the workstation (whether from program failure or system failure) crashes while a client-atomic transaction is outstanding, part of the transaction may have already been written to the database and cannot be automatically backed out.
Server-atomic transactions offer the same benefits as client-atomic transactions and, in addition, offer protection from workstation crashes. If a program (or the system) crashes while a server-atomic transaction is outstanding, the full transaction can be automatically backed out.
Server-logged transaction control offers the same benefits as server-atomic transaction control and, in addition, offer a rollback capability. System rollback restores the system to its status as of a specified point in time. For example, if your company payroll processing was started at 1 p.m. and then something went badly awry later in the afternoon, you could use this functionality to roll back the state of your system to the way it was at 1 p.m., so you could start again. Note that all transaction processing done after 1 p.m. would be affected, not just the payroll.
This attribute can only be set inside a Structure_Start ... Structure_End operation.
This attribute is part of the basic set of attributes that must be supported by All Drivers. It however does not make any sense in some back ends. That is why the Pervasive.SQL will return DF_FILE_TRANSACTION_SERVER_ATOMIC and SQL Based Database Drivers will return DF_FILE_TRANSACTION_SERVER_LOGGED for every table accessed. Trying to set the attribute will be ignored.
The Embedded Database supports the values DF_FILE_TRANSACTION_NONE, DF_FILE_TRANSACTION_CLIENT_ATOMIC and DF_FILE_TRANSACTION_SERVER_ATOMIC.
Client Atomic Transactions in the Embedded Database
Once Begin_Transaction has been executed, all database changes are written to a virtual transaction file. There are actually only three operations that have to be saved in the transaction file. When you edit a record, the old contents of the changed fields, the record number, and the file number are saved. When you delete a record, the whole record, the record number and the file number are saved. When you write a new record, the record number of the new record and the file number are saved.
When the transaction is committed, the current contents of the transaction file are discarded. The transaction-abort process is more complicated, but basically the transaction file is read backwards sequentially. As each table change is encountered, the appropriate action is taken to back out the change. New records are deleted; deleted records are restored (with the original record numbers), and edited records are changed back to their original contents. Therefore, the tables are put back into the exact state they were in prior to the transaction. This works even for tables that do not allow reuse of deleted records. Once the transaction is backed out, the contents of the transaction file are discarded. If you terminate your program with a transaction in progress, an automatic transaction abort will occur.
Since we are writing to a "virtual transaction file", the file will use extended and/or expanded memory with only the overflow actually being written to disk. Since the transaction file will never contain more than one transaction’s data, it is most likely that memory will not be overflowed and no actual disk I/O will ever occur.
Client-atomic transaction processing does not protect a database from a crash. This means that if a transaction was in progress and the system crashes (maybe because of a power failure), or your program terminates abnormally, the transaction will be partially completed. You would then have to either manually fix up the files or restore the files from backup.
There is also no protection from I/O errors. If you get an I/O error during a database operation that is part of a transaction, you can attempt to abort the transaction. However, there is no guarantee that the abort will work correctly. It is also possible to get an error during the abort process itself. In either case, Abort_Transaction would return an error and you would probably want to restore the files from backup.
A lock is in effect during a transaction. While this prevents other processes from writing to the files, it does not prevent them from reading. This means that, just as when not using transaction processing, another process can read a partially complete transaction.
Server Atomic Transactions in the Embedded Database
The DF_FILE_TRANSACTION_SERVER_ATOMIC value is obsolete. It was only used for NetWare TTS, which is no longer supported.
Procedure ShowTransaction
Handle hTable
String sTable sTransaction
Integer iTransaction
Move 0 To hTable
Repeat
Get_Attribute DF_FILE_NEXT_USED Of hTable To hTable
If (hTable > 0) Begin
Open hTable
Get_Attribute DF_FILE_LOGICAL_NAME Of hTable To sTable
Get_Attribute DF_FILE_TRANSACTION Of hTable To iTransaction
Case Begin
Case (iTransaction = DF_FILE_TRANSACTION_NONE)
Move "NO Transaction" To sTransaction
Case Break
Case (iTransaction = DF_FILE_TRANSACTION_CLIENT_ATOMIC)
Move "Client Atomic Transaction" To sTransaction
Case Break
Case (iTransaction = DF_FILE_TRANSACTION_SERVER_ATOMIC)
Move "Server Atomic Transaction" To sTransaction
Case Break
Case (iTransaction = DF_FILE_TRANSACTION_SERVER_LOGGED)
Move "Server Logged Transaction" To sTransaction
Case Break
Case End
Showln sTable " -- " sTransaction
Close hTable
End
Until (hTable = 0)
End_Procedure
The sample procedure above show the transaction type of every table in the filelist.
Procedure ChangeTransaction Integer iOrgTransaction Integer iNewTransaction
Handle hTable hStruct
Integer iTransaction
If (iOrgTransaction = iNewTransaction) ;
Procedure_Return
Move 0 To hTable
Repeat
Get_Attribute DF_FILE_NEXT_USED Of hTable To hTable
If (hTable > 0) Begin
Open hTable Mode DF_EXCLUSIVE
Get_Attribute DF_FILE_TRANSACTION Of hTable To iTransaction
If (iTransaction = iOrgTransaction) Begin
Move hTable To hStruct
Structure_Start hStruct
Set_Attribute DF_FILE_TRANSACTION Of hStruct To iNewTransaction
Structure_End hStruct
End
Else ;
Close hTable
End
Until (hTable = 0)
End_Procedure
The sample procedure above changes every table in the filelist that uses a given transaction type to another transaction type.