Limitations of synchronization models

The following are some restrictions of synchronization models:

Changes made outside the model cannot be redeployed If you deploy a synchronization model and then make changes to it outside the model, those changes are not saved in the model. This practice is fine if you want to use the model as a starting point, deploy, and then make all your changes outside the model. However, if you want to redeploy the model, you are better off making your changes to your MobiLink project so that they are saved and can be redeployed.
Versions A synchronization model can have only one version. See Script versions.
MobiLink system database You cannot use a MobiLink system database that is separate from the consolidated database when deploying a synchronization model. See MobiLink system database.
Multiple publications You cannot create multiple publications. After you have deployed your model you can add more publications using non-model methods such as the CREATE PUBLICATION statement, but you cannot reverse-engineer these additions back into your model. See Publications.
Views It is not possible to select a view when you are selecting consolidated database tables for table mappings.
Computed columns You cannot upload to computed columns in a consolidated database table. If you deploy a synchronization model with computed columns, the deployment may have errors creating the trigger used for timestamp-based downloads. You can either exclude the column from synchronization, or configure the table as download-only (and either use snapshot download or edit the generated consolidated SQL file to remove the computed column from the trigger definition).
Copying computed columns causes a syntax error when deploying the new remote schema to create a new remote database. When dealing with computed columns you should do one of the following:
- Deploy the synchronization model to an existing remote database.
- Exclude the computed column from the remote schema. Note that if you want to synchronize a consolidated database table that has computed columns, you cannot upload to the table.
The Microsoft SQL Server AdventureWorks sample database contains computed columns. Set the columns to be download-only or exclude the columns from synchronization when using this database to create a model.

Deployment considerations

Spatial columns Spatial columns are copied, though the spatial subtype and SRID may not be copied if the consolidated RDBMS does not have metadata support for obtaining those, such as the ST_GEOMETRY_COLUMNS view of the SQL/MM standard. Spatial support in UltraLite is limited to one type (ST_GEOMETRY) that only supports point values and column SRID constraints of SRID=0 or SRID=4326, so you may get a warning or error when deploying an incompatible spatial type to a new UltraLite database.
Long object names The database objects that are created when deploying may have names that are longer than the database supports (because the new object names are created by adding suffixes to the base table names). If this happens, deploy only to file (not directly to a database) and edit the generated SQL file to replace all occurrences of the name that is too long.
New remote schemas If you create a new remote schema in the Create Synchronization Model Wizard, the new remote database columns do not contain indexes of the columns in the consolidated database. Foreign keys and default column values are copied to the new remote database, however, this support relies on database metadata returned by the ODBC driver and syntax or other errors may occur due to driver problems. For example, if a driver reports a default column value in a format that cannot be used to declare such a default in a SQL Anywhere or UltraLite remote database, then errors can occur (including syntax errors when deploying).
UltraLite does not support NCHAR(n), NVARCHAR(n), or LONG NVARCHAR column types. When deploying a synchronization model to a new UltraLite database, such columns in the remote schema are converted to CHAR(4n), VARCHAR(4n), or LONG VARCHAR. If 4n is larger than the maximum length for CHAR and VARCHAR, the maximum length is used and you get a warning.

You can use an existing remote database to create a synchronization model or to update the remote schema in a model.
Proxy tables It is possible to synchronize with consolidated database tables that are proxy tables to another database, but you need to add the TIMESTAMP column to both the base table and the proxy table if you use a TIMESTAMP column for timestamp-based downloads. The Deploy Synchronization Model Wizard cannot add a column to a proxy table or its base, so you either need to use an existing column on both the base and proxy, or you need to use a shadow table or snapshot download.
Materialized views If you are using timestamp-based downloads and have chosen to add a TIMESTAMP column to consolidated tables, you must disable any materialized views that depend on the tables before deploying. Otherwise you may get errors when trying to alter the tables. For SQL Anywhere consolidated databases, use the sa_dependent_views system procedure to find out if a table has dependent materialized views. See sa_dependent_views system procedure.

Other considerations

Creating remote databases based on an Oracle consolidated database When you are using an Oracle consolidated database as the basis for your SQL Anywhere or UltraLite remote database, you may want to change DATE columns in the consolidated database to TIMESTAMP. Otherwise, sub-second information is lost on upload.

Discuss this page in DocCommentXchange.