The DB Bulk Insert Into action appends the data submitted via the XPath expression of the Values field as new rows into the DB table that is selected in the DB Bulk Insert Into setting (see screenshot below).
•DB Bulk Insert Into: When selecting the DB table into which to insert, you specify the DB connection method and then select the table into which the new rows are to be inserted. The new rows will be appended to the existing rows of the table. The selected table is listed in the DB Bulk Insert Into field, together with its columns. For example, in the screenshot above, the selected table is named B, and it has two fields, named Field1 and Field2.
•Other table: A table other than the one selected in DB Bulk Insert Into can be specified via an XPath expression. The new rows will be inserted into this table as well. This table must already exist, and it must contain columns with the same names as the table columns selected in DB Bulk Insert Into. It can contain additional columns if these have default values or are nullable. Also, the datatype of each column must match the datatype of the corresponding column of the table selected in DB Bulk Insert Into. In the screenshot above, the new rows will be inserted into the table NewDB. If the insertion is to be successful, the NewDB table must have two columns with the names Field1 and Field2, respectively. The datatypes too must match: the first column being of a number datatype, the second column being of a string datatype. If submitted values do not match a column's datatype, then a conversion is attempted.
•Values: The XPath expression of the Values field must return a sequence of arrays, where each array represents a row and where each value in an array represents a column value. In the screenshot above, each array is placed on a new line. Notice the various ways the array items are instantiated.
In the screenshot above, we have used a Reload action to update the DB page source that contains the modified table.
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 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.