DF_FILE_TRANSACTION

See Also: Get_Attribute, Set_Attribute

 

Indicates the type of transaction processing for the table.

Level

Table

Supported by

All Drivers

Type

Enumeration list, permanent

Access

Read / Write

Values

DF_FILE_TRANSACTION_NONE, DF_FILE_TRANSACTION_CLIENT_ATOMIC, DF_FILE_TRANSACTION_SERVER_LOGGED

DF_FILE_TRANSACTION_SERVER_ATOMIC (obsolete)

Remarks

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.