What's New in Sync Framework 2.1

Článek
07/07/2014

Sync Framework 2.1 includes new and enhanced features in the following areas:

Database providers
- SQL Azure Synchronization
- Bulk Application of Changes
- Parameter-based Filtering
- Removing Scopes and Templates
- Upgrading the Metadata Format
- SQL Server Compact 3.5 SP2 Compatibility
- Obsolete Members
- Breaking Changes

Database Providers

Sync Framework 2.1 introduces new features that let you synchronize a SQL Server or SQL Server Compact database on your computer with a database. This release also introduces parameter-based filtering, the ability to remove synchronization scopes and templates from a database, and performance enhancements to make synchronization faster and easier.

SQL Azure Synchronization

With Sync Framework 2.1, you can extend the reach of your data to the web by leveraging the Windows Azure Platform and . By synchronizing a SQL Server database on your business premises to , you make some or all of your data available on the web without the need to provide your customers with a connection to your on premises SQL Server database. After you configure your database for synchronization, users can take the data offline and store it in a client database, such as SQL Server Compact or SQL Server Express, so that your applications operate while disconnected and your customers can stay productive without the need for a reliable network connection. Changes made to data in the field can be synchronized back to the database and ultimately back to the on premises SQL Server database. Sync Framework 2.1 also includes features to interact well with the shared environment of Windows Azure and . These features include performance enhancements, the ability to define the maximum size of a transaction to avoid throttling, and automatic retries of a transaction if it is throttled by Windows Azure. All of this is accomplished by using the same objects you use to synchronize a SQL Server database, such as SqlSyncProvider and SqlSyncScopeProvisioning, so you can use your existing knowledge of Sync Framework to easily synchronize with .

Sync Framework gives you flexibility in the way you structure your synchronization community, but two typical ways are to use a 2-tier architecture or an N-tier architecture.

2-tier architecture: Sync Framework runs on the local computer and uses a SqlSyncProvider object to connect directly to the database without going through a middle tier or a web server, such as Internet Information Services (IIS). For more information, see How to: Configure and Execute Synchronization with SQL Azure [Delete].
N-tier architecture: A Sync Framework database provider runs in a Windows Azure hosted service and communicates with a proxy provider that runs on the local computer. For more information, see How to: Deploy Sync Framework to Windows Azure [Delete].

Bulk Application of Changes

Sync Framework 2.1 takes advantage of the table-valued parameter feature of SQL Server 2008 and to apply multiple inserts, updates, and deletes by using a single stored procedure call, instead of requiring a stored procedure call to apply each change. This greatly increases performance of these operations and reduces the number of round trips between client and server during change application. Bulk procedures are created by default when a SQL Server 2008 or database is provisioned. For more information, see How to: Provision and Deprovision Synchronization Scopes and Templates (SQL Server) or Tuning and Monitoring Performance.

Parameter-based Filtering

Sync Framework 2.1 enables you to create parameter-based filters that control what data is synchronized. Parameter-based filters are particularly useful when users want to filter data based on a field that can have many different values, such as user ID or region, or a combination of two or more fields. Parameter-based filters are created in two steps. First, filter and scope templates are defined. Then, a filtered scope is created that has specific values for the filter parameters. This two-step process has the following advantages:

Easy to set up. A filter template is defined one time. Creating a filter template is the only action that requires permission to create stored procedures in the database server. This step is typically performed by a database administrator.
Easy to subscribe. Clients specify parameter values to create and subscribe to filtered scopes on an as-needed basis. This step requires only permission to insert rows in synchronization tables in the database server. This step can be performed by a user.
**Easy to maintain.**Even when several parameters are combined and lots of filtered scopes are created, maintenance is simple because a single, parameter-based procedure is used to enumerate changes.

For more information, see How to: Filter Data for Database Synchronization (SQL Server).

Removing Scopes and Templates

Sync Framework 2.1 adds the SqlSyncScopeDeprovisioning and SqlCeSyncScopeDeprovisioning classes to enable you to easily remove synchronization elements from databases that have been provisioned for synchronization. By using these classes you can remove scopes, filter templates, and the associated metadata tables, triggers, and stored procedures from your databases. For more information, see How to: Provision and Deprovision Synchronization Scopes and Templates (SQL Server).

Upgrading the Metadata Format

The metadata format for the database providers changed in Sync Framework 2.1. The new metadata format is incompatible with previous versions of the database providers. The upgrade to the new metadata format cannot be undone, and when you try to use an earlier version of the database providers to synchronize a database that is in the 2.1 format, Sync Framework throws an exception. However, the SqlSyncProvider class in Sync Framework 2.1 detects whether the metadata is in the 2.0 or 2.1 format, and operates in a backward compatibility mode to synchronize a database that contains metadata in the 2.0 format. Sync Framework can synchronize a database in the 2.0 format with a database in either the 2.0 or the 2.1 format. Therefore, it is not necessary to upgrade all of the databases in your synchronization community at the same time. For example, in an N-tier architecture you can upgrade the server Sync Framework components and database metadata format and continue to synchronize with clients that use Sync Framework 2.0. Clients can then upgrade when it is convenient for them to do so.

For more information about backwards compatibility and version interoperability, see Sync Framework Backwards Compatibility and Interoperability.

For more information about how to upgrade the databases in your synchronization community, see Upgrading the Database Synchronization Community.

SQL Server Compact 3.5 SP2 Compatibility

The Sync Framework 2.1 SqlCeSyncProvider database provider object uses SQL Server Compact 3.5 SP2. Existing SQL Server Compact databases are automatically upgraded when Sync Framework connects to them. Among other new features, SQL Server Compact 3.5 SP2 makes available a change tracking API that provides the ability to configure, enable, and disable change tracking on a table, and to access the change tracking data for the table. SQL Server Compact 3.5 SP2 can be downloaded here.

Obsolete Members

The following members are obsolete and should not be used in new development. They continue to function as expected in Sync Framework 2.1, but might be removed in a later version.

Obsolete Members in Managed Code

Constructors for the SqlSyncScopeProvisioning class that do not have a SqlConnection parameter: #ctor and #ctor(DbSyncScopeDescription). Instead, use a constructor with a SqlConnection parameter, such as #ctor(SqlConnection). Also, be aware that when you use an obsolete version of this constructor, Sync Framework assumes a database edition of SQL Server 2005 and disables the use of bulk procedures for insert, update, and delete.
Methods of the SqlSyncScopeProvisioning class that have a SqlConnection or database name parameter: Apply(SqlConnection), ScopeExists(String, SqlConnection), and Script(String). Instead, set the connection in the SqlSyncScopeProvisioning constructor and use the methods without the connection parameter: Apply, ScopeExists(String), and Script.
Constructors for the SqlCeSyncScopeProvisioning class that do not have a SqlCeConnection parameter: #ctor and #ctor(DbSyncScopeDescription). Instead, use a constructor with a SqlCeConnection parameter, such as #ctor(SqlCeConnection).
Methods of the SqlCeSyncScopeProvisioning class that have a SqlCeConnection parameter: Apply(SqlCeConnection) and ScopeExists(String, SqlCeConnection). Instead, set the connection in the SqlCeSyncScopeProvisioning constructor and use the methods without the connection parameter: Apply and ScopeExists(String).

Breaking Changes

The following changes occurred between Sync Framework 2.0 and Sync Framework 2.1.

The database provider classes in the Microsoft.Synchronization.Data.SqlServerCe namespace require SQL Server Compact 3.5 SP2. Sync Framework methods that connect to a SQL Server Compact database throw an exception when an invalid version of SQL Server Compact is installed. If you have an existing database that synchronizes with an earlier version of Sync Framework, when you upgrade Sync Framework and SQL Server Compact and connect to the database by using a Sync Framework method, your database is automatically updated. For more information, see Upgrading SQL Server Compact.
The default option for creating tables and procedures when provisioning a SQL Server database by using a SqlSyncScopeProvisioning object has changed from Create to CreateOrUseExisting. When you provision a database without specifying new values for the creation options, tables and procedures are created if they do not already exist in the database.

Sdílet prostřednictvím