Working with Table Schemas
This topic describes several ways in which you can work with the table schemas that are created in client and peer databases.
Client and Server Synchronization
During the initial synchronization session for a client, Sync Framework creates tables in the client database. For more information, see How to: Initialize the Client Database and Work with Table Schema. After those tables are created, some schema changes are allowed.
Sync Framework does not automatically propagate schema changes from the server to the client. For information about how to handle schema changes on the server, see Deploying and Versioning Applications. The following schema changes are supported in the client database:
Drop tables. The behavior during the next synchronization depends on the value that you specified for CreationOption. If you do not want the table on the client at all, remove it from the SyncTableCollection. When you drop a table that has change tracking enabled, you also drop the system table that tracks delete operations for that table. Therefore, any delete operations since the last synchronization are not uploaded to the server.
Add new columns.
Drop columns for tables that are involved in snapshot synchronization. This change is not supported for other types of synchronization.
Add, drop, and rename indexes.
Add, drop, and rename primary keys and other constraints.
Modify defaults.
All other changes are not supported and can cause synchronization failures.
In some applications, the schema is different at the client and server. The following points summarize the behavior for a table and the ADO.NET dataset that Sync Framework uses to update that table at the client:
If the dataset contains Column1 and Column2, and the table contains Column1, Column2, and Column3: The values in Column1 and Column2 are applied, and Column3 is set to its default value or NULL if the column does not have a default.
If the dataset contains Column1, Column2, and Column3, and the table contains Column1 and Column2: The values in Column1 and Column2 are applied, and Column3 is ignored.
If the dataset contains Column1, Column2, and Column3, and the table contains Column1 and Column2, and Column4: The values in Column1 and Column2 are applied; Column3 is set to its default value or NULL if the column does not have a default; and Column4 is ignored.
Peer-to-Peer Synchronization
Peer-to-peer synchronization does not provide automatic initialization of peer databases or create a change tracking infrastructure at each peer. For information about schema and data initialization, see " Initializing a Server Database " in How to: Configure and Execute Collaborative Synchronization (Non-SQL Server). There are no restrictions on schema changes to base tables in peer databases. However, applications must ensure that the commands that select and apply changes are updated if any schema changes occur. For example, if you add a column to a table, the command to insert changes into that table must be updated to include the new column.
In peer-to-peer scenarios, the schema might differ between peer databases. For example, a table schema at the first peer might use numerical column names that are not easy to read. You can use the DbSyncColumnMapping and DbSyncColumnMappingCollection objects to map the columns to more friendly names for other peers.