Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

SQL Anywhere 11.0.1 (Français) » MobiLink - Server Administration » MobiLink Server APIs » Direct row handling » Introduction to direct row handling


Development tips for direct row handling

Unique primary keys

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.

Column Names

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:

Use the last download time for downloads

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 methodology.

See Timestamp-based downloads.

Transaction management for uploads

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.

Handle errors

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.

Class instance

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.