For MobiLink synchronization, including direct row handling, your data source must have unique primary keys that are not updated.
In a non-relational data source such as a spreadsheet or text file, this means that one column must contain unique, unchanging
values that identify the row.
When using direct row handling, the column names of tables are only available if the MobiLink client is configured to send
column names. Alternatively, you can use column indexes to access row information.
If possible, set up your direct row handling application like a timestamp-based SQL application; maintain a last_modified
column and download data based on it. This method avoids unforeseen problems that could occur if you use a different download
You cannot commit transactions with the MobiLink consolidated database. However, you can commit transactions with your direct
row handling data source. When setting up transaction management, keep the following tips in mind:
Commit the upload before MobiLink commits
When applying an upload, MobiLink commits the changes at the end of the end_upload event. You should make sure that
all upload changes that you want to keep are committed before the end of your end_upload script. Otherwise, if there is an
error or failure you may get into a state in which your application thinks that the upload is applied but MobiLink has not
applied the data, which could result in lost data.
Handle redundant uploads
When an error or failure occurs after your application commits an uploaded row and before the MobiLink server commits
it, the MobiLink server and your data source may get in an inconsistent state. You can solve this problem by allowing redundant
uploads and having logic in place to make sure the redundant upload is applied properly. In particular, when your application
sends the upload a second time, it should not be applied again.
To handle errors, ensure you employ appropriate transaction management, as described above. In addition, your Java or .NET
code that handles rows must send any exception that occurs to the MobiLink server. If an error occurs before the MobiLink
server or your application has committed changes, MobiLink rollbacks the transaction and maintains a consistent state with
For direct row handling, MobiLink creates one class instance per database connection. The class instance is not destroyed
at the end of a synchronization: it is destroyed when the database connection is closed. Class level variables retain values
from previous synchronizations.