Changes made outside the model cannot be redeployed   If you deploy a model and then make changes to it outside the model, those changes are not saved in the model. This is fine if you want to use the model as a starting point, deploy, and then make all your changes outside the model. But if you want to be able to redeploy the model, you are better off making your changes in Model mode so that they are saved and can be redeployed.

DB2 mainframe   MobiLink models do not work with DB2 mainframe consolidated databases.

MobiLink system database   You cannot use a 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.

Views   When you are selecting consolidated database tables for table mappings, it is not possible to select a view.

Generated remote database   If you create a new remote schema in the Create Synchronization Model Wizard, the new remote database columns do not contain the foreign keys, indexes, or default column values of the columns in the consolidated database. UltraLite databases do not support NCHAR or NVARCHAR columns, so you cannot use consolidated database tables with columns of those data types to generate a new remote schema for an UltraLite remote database. After deploying, you can create or change the remote schema and then update the schema for the model.

Computed columns   If you want to synchronize a consolidated database table that has computed columns, you cannot upload to the 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:

The Microsoft SQL Server AdventureWorks sample database contains computed columns. If you use this database to create a model, set the columns to be download-only or exclude the columns from synchronization.

Logical deletes   The MobiLink synchronization model support for logical deletes assumes that a logical delete column is only on the consolidated database and not on the remote database. When copying a consolidated schema to a new remote schema, leave out any columns that match the logical delete column in the model's synchronization settings. For a new model, the default column name is deleted.

To add the logical delete column name to the remote schema:

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 meta data 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).

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: either deploy to an existing remote database to avoid using the model's remote schema, or load the

UltraLite databases do not support NCHAR or NVARCHAR columns, so you cannot use consolidated database tables with columns of those data types to generate a new remote schema for an UltraLite remote database.

After deploying, you can create or change the remote schema and then update the schema for the model.

Proxy tables   It is possible to synchronize with consolidated database tables that proxy tables to another database, but if you use a TIMESTAMP column for timestamp-based downloads, then you need to add the TIMESTAMP column to both the base table and the proxy table. 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.

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.

Proxy tables   If you are using shadow tables maintained by triggers, then the triggers and shadow tables should be on the base table. A trigger on a base table can't modify a shadow table in the database that defines the proxy table for the base table.