|
Synchronization models have some limitations.
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 to use the model as a starting point, deploy, and then make all your changes outside the model. However, to redeploy the model, you are better off making your changes to your MobiLink project so that they are saved and can be redeployed.
A synchronization model can have only one version.
You cannot use a MobiLink system database that is separate from the consolidated database when deploying a synchronization model.
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.
It is not possible to select a view when you are selecting consolidated database tables for table mappings.
You cannot upload to computed columns in a consolidated database table. If you deploy a synchronization model with computed columns, then 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, do one of the following:
Deploy the synchronization model to an existing remote database.
Exclude the computed column from the remote schema. 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.
The MobiLink plug-in for SQL Central provides the following support for the Oracle XMLTYPE.
In the remote database, proxy tables cannot be part of a publication.
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.
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.
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, then 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.
It is possible to synchronize with consolidated database tables that are proxy tables to another database, but you must 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 must either use an existing column on both the base and proxy, or you must use a shadow table or snapshot download.
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.
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.