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.
See Maintaining unique primary keys.
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.
To use column names, see:
If at all possible, you should 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 used different download methodology.
See Timestamp-based downloads.
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 your application.
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.
| Send feedback about this page via email or DocCommentXchange | Copyright © 2008, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.0 |