DB Begin Transaction
When the event is triggered the DB Begin Transaction action begins a transaction with the data source selected in the Connection combo box. This combo box lists all the data sources of the project, and also offers the option of setting up an additional database connection specifically for use with the DB Begin Transaction action.
The Transaction Locking option specifies the level of protection, and enables you to ensure that data is not corrupted during write actions. The following options are available:
•Database Default: Collects DB-related default settings on the DB, server, and client.
•Prevent from writing of affected tables: The DB will not be written to if it is currently being written to via another connection. The Write-transaction will be deferred till the other Write-transaction has been completed; otherwise an error message will be displayed.
•Prevent from reading and writing of affected tables: The DB will not be read from or written to if it is currently being written to via another connection. The transaction will be deferred till the other transaction has been completed, or an error message will be displayed.
•Exclusive: This is an SQLite feature. When the EXCLUSIVE transaction is active, other connections are not able to read or write to the DB and get an error to the effect that the DB is locked.
If you connect to an SQLite database, a Timeout (in seconds) property becomes available. This enables you to specify a wait period for applying a write-lock. If no timeout period is specified, SQLite will abort immediately if a write-lock is not applied on transaction begin.
Error processing
The On Error option lets you define what should be done if an error occurs. Since the error handling can be precisely defined for this action, errors on such actions (that provide error handling) are treated as warnings—and not errors. The advantage is that you do not need to check errors on actions for which error handling has already been defined. The following error handling options are available:
•Abort Script: After an error occurs, all subsequent actions of the triggered event are terminated. This is the default action if an error occurs. If you wish to continue despite an error, select either the Continue or Throw option.
•Continue: Actions are not terminated. Instead, you can select what to do in either event: when there is no error (On Success), or when there is an error (On Error). For example, you might want to display a message box saying whether a page load was successful or not.
•Throw: If an error is detected, this option throws an exception that is stored in the Try/Catch action's variable. The Catch part of the Try/Catch action is used to specify what action to take if an error occurs. If no error occurs, then the next action is processed. See the section Try/Catch action for details.
About DB Transactions For each DB access that needs a transaction, one is automatically created and closed afterwards. This might not be desirable for some setups. For example, when you have two DB page sources that you want to update atomically together: If both tables are saved successfully, then the transaction is committed, but rolled back otherwise. To accommodate this kind of situation, transactions can be created on a connection basis.
If you begin a transaction, all DB operations belonging to the same DB connection will use this transaction.
Committing a transaction makes changes visible to the world outside your transaction. Changes can be rolled back. In this case, even if you have done a Save on your page source, the changes won’t be visible after a rollback! Note that any transaction that is not closed (committed or rolled back) when the end of the action tree has been reached will be rolled back automatically! A warning to this effect will be displayed in the Messages window.
It is important to bear in mind that, while the behavior above refers to explicit transaction actions, this behavior also applies to all DB operations that use the same connection as the transaction.
|
MobileTogether extension functions
MobileTogether provides a range of XPath extension functions that have been specifically created for use in MobileTogether designs. Some functions can be particularly useful with specific actions. For example, mt-available-languages() returns the languages in which the solution is available and could, for example, be used with the Message Box action. If a function is especially relevant to this action, it is listed below. For a full list of extension functions and their descriptions, see the topic MobileTogether Extension Functions.
mt-available-db-connection-names()
mt-db-any-changed-fields()
mt-db-any-changed-rows()
mt-db-deleted-original-fields()
mt-db-deleted-original-rows()
mt-db-file-path()
mt-db-modified-fields()
mt-db-modified-rows()
mt-db-new-fields()
mt-db-new-rows()
mt-db-original row()
mt-external-error-code()
mt-external-error-text()