Transaction processing allows you to process several commands as a group, or transaction. For each transaction, you can keep the changes made by the group of commands, or you can undo the changes, for instance if a command error occurs or a transaction cannot be completed.
Transaction processing works in both single and multi-user modes.
Transaction processing offers several advantages, the greatest of which is improved data integrity.
For example, if you are entering debits and credits, you can ensure that either all or none of the data is entered. Or suppose you are posting accounts at the end of the year, and deleting rows as they are posted to a master account. If the posting process is interrupted or a required table is not available, transaction processing lets you cancel the entire process and start over without having to reconstruct each original table.
You can also use transaction processing to analyze data in a hypothetical situation. You can add data to a table, perform calculations, analyze the results, then decide whether to keep the new data. You can try different scenarios as many times as needed to find the right combination of data and keep only the data that produced the desired result.
Transaction processing has the disadvantage of decreasing system performance.
When you use it, R:BASE must keep track of extra table and database locks, maintain a Before Image file for each user, and perform internal consistency checks. Every transaction requires overhead, which slows the entire system.
Transaction Processing Topics:
Locking Table Access and Resource Waiting
Row Locks and Transaction Processing
Automatic Table and Database Locks
Displaying Transaction Processing Locks
Resource Waiting in Transaction Processing
