|
Adding custom synchronization support to UltraLite can involve up to three 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 fractional data is not lost For SQL Anywhere consolidated database this is not typically an issue. However, for databases like Oracle, there may be compatiblity 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 loosing fractional second data when the UltraLite remote databases uploads data to the consolidated database. See Oracle consolidated database and UltraLite precision property.
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. See Designing synchronization in UltraLite.
For example, you may want to create a publication for high-priority data. The user can synchronize this data over high-speed wireless networks. Because wireless networks can have high usage costs associated with them, you would want to limit these usage fees to those that are business-critical only. 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, then initializing the synchronization operation.
Describing the session primarily involves choosing a synchronization communication stream (also known as a network protocol) as well as the parameters for that stream, setting the version of your synchronization scripts, and assigning the MobiLink user. However, there are other parameters you can configure as well: for example, use the upload_only and download_only parameters to change the default bi-directional synchronization to one-way only. See Adding synchronization to your UltraLite application.All other important synchronization behaviors are controlled with MobiLink synchronization scripts. You need multiple scripts because each MobiLink remote database can contain a different subset of the data in the consolidated database.
These include:
What data is downloaded as updates to tables in the UltraLite remote.
What processing is required on uploaded changes from a remote database.
This means that you can write your synchronization scripts so that data is partitioned among remote databases in an appropriate manner.