UltraLite client synchronization behavior customization

Adding custom synchronization support to UltraLite involves several tasks.

• Maintain primary key uniqueness in synchronization models that include more than one remote client

  Required. In a synchronization system, the primary key is the only way to identify the same row in different databases (remote and consolidated) and the only way to detect conflicts. Therefore, multiple clients must adhere to the following rules:

  • Every table that is to be synchronized must have a primary key.
  • Never update the values of primary keys.
  • Primary keys must be unique across all synchronized databases.
• Ensure your date columns are set up so that fractional data is not lost

  For a SQL Anywhere consolidated database this is not typically an issue. However, for databases like Oracle, there may be compatibility issues that you need to consider. For example, UltraLite and Oracle databases must share the same timestamp precision. Additionally, you should also add a TIMESTAMP to the Oracle database to avoid losing fractional second data when the UltraLite remote databases uploads data to the consolidated database.

• Describe what data subsets you want to upload to the consolidated database

  Optional. You only need to do this when you do not want to synchronize all data by default. To target what data you want to synchronize, use one or more subsetting techniques.

  For example, you may want to create a publication for high-priority data. The application could then synchronize this data over wireless networks. Because wireless networks can have high usage costs associated with them, you may want to limit these usage fees to those that are business critical. You can then synchronize less time-sensitive data from a cradle at a later time.

• Initialize synchronization from your UltraLite application and supply the parameters that describe the session

  Required. Programming synchronization has two parts: describing the session, and then initiating the synchronization operation.

  Describing the session primarily involves choosing a synchronization communication stream (also known as a network protocol), and the parameters for that stream, setting the version of your synchronization scripts, and identifying the MobiLink user. However, there are other parameters you can set: for example, use the upload_only and download_only parameters to change the default bi-directional synchronization to one-way only.

All other important synchronization behaviors are controlled at the MobiLink server with MobiLink synchronization scripts. These include:

• What data is downloaded as updates or inserts to tables in the UltraLite remote.

• What processing is required on uploaded changes from a remote database.

You can write your synchronization scripts so that data is partitioned among remote databases in an appropriate manner.