Backup/Restore SQLite DB
This action (screenshot below) enables you to backup an SQLite database multiple times to a folder you designate. You can subsequently restore the SQLite database from one of these backups. This feature is available only on MobileTogether Server Advanced Edition.
To set backups, do the following:
2.Select the SQLite DB connection that you want to back up.
3.Select the folder where the backups should be stored. This can be a path that is relative to the server-side solution's working directory or an absolute path. The filename of the backed up SQLite database will be generated automatically and is a concatenation of (i) the DB connection name that you entered in Step 2 (for example, Contract_Management in the screenshot above) and (ii) the current timestamp (in the format YYYY-MM-DD HH-MM-SS). So, for example, a possible filename would be: Contract_Management 2021-06-18_10-30-24, where the numbers are the date and time.
4.Optionally, enter the maximum number of backups. After this number is exceeded, the oldest backup will be deleted. If no value is set or if a value of 0 is set, then an unlimited number of backups is allowed.
To restore the SQLite database from a backup, do the following:
2.Select the connection to the SQLite DB that you want to restore.
3.Select the relative or absolute path of the backup file from which to restore. Relative paths must be be relative to the server-side solution's working directory.
•After a backup has been created, the path to it can be obtained by calling the mt-last-file-path() function. Note that this function returns the full file path.
•When a SQLite database is restored via the Restore action, any new data in the replaced database file (since the last backup) will be lost. If you want to keep this data make sure that you back up the database before restoring it.
•After a backed up file is restored via the Restore action, the backup file is not deleted. After a Restore action, the mt-last-file-path() function returns the full path of the backup file (that was used for the restore).
•If the DB is locked when a restore is attempted, an error is returned. There are no retries or timeouts.
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.
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.