Sync Services: Thoughts on Schema Creation

Article
02/28/2007

In typical database to database sync scenarios where the backend database is SQL Server, the sync framework creates the schema for the tables undergoing synchronization on the client database. All that is needed is to have the SelectIncrementalInsertsCommand or SelectIncrementalUpdatesCommand supplied on the SyncAdapter object corresponding to the table in question. The sync runtime queries the database for the schema and provide it to the client as a dataset. This logic also works with none SQL Server backend however this process is subject to failure. The reason is that the schema obtained from the server might, and most likely will, have different data types which SqlCe on the client does not know how to map to its supported data types. Even with SQL Server as the backend, some data types are not supported on SqlCe and will lead to the same failure.

In no so typical scenarios where the server is not a relational store, the runtime won’t be able to find the schema in the first place.

There has to be a way to address table schema creation issues. The SyncServerProvider has a property called SyncSchema. This property is set to null by default. However, if your scenario fall one of the above scenarios, then you ought to take a look at the SyncSchema type. SyncSchema has the same look and feel of a DataSet with few more additions to simplify setting up a table schema. By passing a SyncSchema instance to the SyncServerProvider, you explicitly disable the dynamic schema query logic and instruct the provider to pass your custom made schema instead.

While dynamic generation of schema is an attractive feature, it does not come for free. Therefore hand crafted SyncSchema object is still a good practice even if there is no type difference issues between server and client tables.

Sync Services: Thoughts on Schema Creation

Additional resources