PowerBuilder Application Development Series Lecture (1) Zhang Jianzi
In the database, the so-called transaction refers to a set of logical operating units that convert the data from one state to another. To ensure consistency in the database, the data manipulation should be a discrete group logic unit: When it is completed, the consistency of data can be maintained, and when a part of this unit fails, the entire transaction should be all For errors, all the operations from the starting point should all fall back to the start state.
The operation of the transaction is this: first define a transaction, then modify the data, if you submit (commit), these modifications are permanently saved, if the rollback, the database management system will give up All modifications you have returned to start transactions. In addition, some database supports the "SavePoint" "SavePoint": that is, you can make the current state store in any point in a transaction process, just return to the storage point you set, not Return to all transactions. If your transaction can be divided into several groups of changes to the database, you can set multiple storage points, as needed, you can return to any of the storage points without making all transactions to modify the data.
Correctly managing transactions to ensure data integrity, when you do all the work is completed and given, there is no data to physically write into the database. Let us look at such an example, we have such a bank application system, the front desk user makes the operation of the depositor's one hundred deposits to save the depositor; in the database, the record points of these two customers Stored in two tables, when the user makes it up on the screen, two tables need to be modified in the background. If you subtract one hundred yuan in the database, the previous table must return to the state before the modification of the operation of the other hundred yuan, the previous table must return to the state before the modification, otherwise the content of the database Do not unify, the household households lose one hundred yuan, and the information is inevitable. Therefore, transaction management is necessary.
Traditionally, we believe that a transaction includes modifications to one or more tables, and with the development of distributed databases and data warehouses, transactions may include modifications to one or more databases. In the above example, the two users may be a different user, and the information is stored in different databases in different geographies, and one of the above transactions involve the operation of different databases.
Transaction Management in PowerBuilder acts as a database of reception development tools Power-Builder supports transaction management. In Power-Builder, there is an object called transaction, which is a communication area with a PowerBuilder application and a database. PowerBuilder creates a global transaction object SQLCA at the beginning of the application. Since most applications use only one database, the general developers mainly use SQLCA as transaction objects connected to the unique database.
The statement for transaction management in PowerScript has four: Commit, Rollback, Connect, disconnect.
When you need to apply the connection with the database to create this command, execute disconnect when you cancel the connection, which generally uses the start and end of the application, which is also used in the Open and Close events of Appli-Cation, respectively.
When the database modification of a transaction is successfully completed, the modification must be submitted to the database, and the COM-MIT statement is the end of an older transaction and a new transaction starting. Before the modification is submitted, the database has not been truly modified, and these modifications are retained in a workspace, and only the modified users can see these modified values, after commit, all users are all You can see the new value.
In the process of transaction, some errors are happened or in operation. It is necessary to stop the transaction in operation. You must use the rollback command to return the transaction. If the operation is not written without the rollback command, these operations must be incorrect as the next transaction Part of the decline in the database.
If you are using a multi-window application, just one transaction object, you should pay more attention to Roll-back and commit will affect the logic consistency of the transaction. These two instructions performed in a window will make or fall back in other window applications.
In multi-user systems, the closer the time of modification and submission, the higher the possibility of submitting success. Because all SQL statements in a transaction are all executed, it is entirely possible, for example during your transaction, another user has modified data and submitted, which is likely to make your changes invalid, then Commits will fail, you must fall back to all of this business.
The AutoCommit property of the transaction object has an AutoCom-MIT property that enables developers to simplify the operation of transaction management, which can be assigned with TRUE or FALSE. When it is true, PowerBuilder does not transfer your SQL statement to the background database through other additional interactions, and performs automatic submission. Of course, you can set the AutoCommit property as a false (default), submit or fall back in keywords such as commit or rollback. In most applications, a part of the database operation is to group committed, while others are not available. So we can use AutoCommit's characteristics to determine the starting point of the transaction. When we set the AutoCommit property to false, the system settings the starting point for transactions at this time. When AutoCommit is true, the system automatically takes this transaction. So you can set the autoCommit to true, when you need to start a transaction, set it to false, this is the transaction start point.
The greatest advantage of this transaction management within PowerBuilder is convenient. You don't think about the entire transaction, but just submit or roll it back to your modifications. However, convenient and controllability is always contradictory, there is no mechanism for storage points and nested transaction management in Power-Builder, even if the database you are using, it is not possible in PowerBuilder. However, in ordinary applications, storage points and nested transactions are not required, and general transaction management is enough.
Transaction management instructions with databases Implementing the above-mentioned transaction management despite simple and convenient, in some applications, we also need to utilize the nested transactions and storage points of the database system used, while transaction management within PowerBuilder Without this feature, you must design it yourself.
The way you use your own transaction management is the transaction instructions directly using the database itself. When you use your own management, you should stop the management transaction, which sets Auto-Commit to True, and the system will not automatically construct the transaction command. Implementing manual affairs management is to use the PowerBuilder instruction of ExecuteImmedi ATE to perform any database operation. What you need to do is to edit the database command into a string, you can perform any data definition statement such as the metrics, build primary keys, stored procedures, etc. You can use Execute Immediate Begin Transaction Trans-Name. Such an instruction starts a transaction. With this approach, as long as the database you have supported supports transaction management such as nested transactions and storage points, our applications developed through PowerBuilder can also be achieved.
The method of transaction management provided in PowerBuilder is a variety of diversified, as long as you are flexible, you can design outstanding database applications.
