共用方式為

Overview [Synchronizing Databases]

  • 發行項

Sync Framework enables synchronization between databases. It provides an intuitive and flexible API that enables you to build applications that target offline and collaboration scenarios. The API enables you to use all or only some of the components that are provided, depending on the architecture and requirements of an application. Sync Framework supports client-server, client-to-client, and mixed topologies. In client-server topologies, all clients synchronize with a central server. In client-to-client topologies, each client can synchronize with another client without changes having to go through a central server. Mixed topologies consist of a combination of client-to-client and client-server topologies.

Comparing Sync Framework to Other Technologies

Microsoft offers several technologies that are designed for applications that perform synchronization.  The most significant technologies are as follows:

  • Remote Data Access (RDA) This is used to synchronize a SQL Server Compact database with a database on another edition of SQL Server.

  • Merge replication This is used to synchronize different editions of SQL Server, and includes SQL Server Compact.

Use the following table to help you determine which technology is appropriate for the applications that you want to build.

Key feature

RDA

Merge replication

Sync Framework

Synchronize by using services

No

No

Yes

Supports heterogeneous databases

No

No

Yes

Incremental change tracking

No1

Yes

Yes

Conflict detection and resolution

No

Yes2

Yes

Automatically initialize schema and data

Yes

Yes

Yes

Supports large data sets

Yes

Yes

Yes

Automatically propagate schema changes

No

Yes

No

Automatically repartition data

No

Yes

No

1 RDA supports incremental uploads, but downloads are always a snapshot that updates all the data on the client. Sync Framework uses net change tracking, in which the last version of a row is synchronized.

2 Merge replication provides built-in conflict resolution. Sync Framework provides a framework for building a conflict-resolution scheme. For more information, see How to: Handle Data Conflicts and Errors for Database Synchronization (SQL Server).

Sync Framework provides the flexibility of a programming model like offline datasets and a richer synchronization feature set like that found in merge replication. Sync Framework functionality is superior to RDA. Merge replication provides significant functionality with configuration available through wizards, stored procedures, and its own API. Sync Framework is intended for developers, and enables a developer to easily create views of data on the client that are based on a server database or another data source. Sync Framework supports heterogeneous databases and synchronization over services, such as Windows Communication Foundation (WCF). If the application involves synchronizing with non-SQL Server databases, or if the application must have separate components to enable synchronization over different transports or services, use Sync Framework.

For some applications, the decision to use a technology is easy: If you must have separate components to enable synchronization over different transports or services, or synchronize a data source other than a database, Sync Framework is the solution. If you are a database administrator who is designing a system for scalability and high availability, or who wants to configure synchronization without much programming, replication is a better choice. Ultimately, you must carefully consider the application requirements and determine whether the Sync Framework API is the appropriate technology to use. If you want to move beyond replicating a schema and its data from one database to another, we recommend that you use Sync Framework.

Synchronization Scenarios

The ability to support mobile and remote workers is becoming more important for organizations every day. It is very important for organizations to make sure that workers have access to the same information that they have when they are in the office. In most cases, these users will have a laptop, office desktop, smartphone, or PDA. From these devices, users can sometimes access data by using a VPN connection or some other method of connecting directly to the corporate network. For most remote users, this solution is less than satisfactory because of major disadvantages in the following areas:

  • Network requirements

    To enable users to access information, the remote device must have a constant connection to the corporate network while it is accessing data. For some workers, such as those who are working from home, this might not be a problem. For other users, such as salespeople who are constantly on the move, this could be more difficult. For example, if a salesperson is visiting a customer and cannot access inventory data because there is no network connectivity, the salesperson cannot effectively do her job.

  • Data access speeds

    In a typical client-server corporate environment, users have high speed networks that enable quick access to information. However, remote workers are often connected over slow, unreliable networks. By using a typical solution, every piece of data that a user wants must be downloaded every time that it is requested, because there is no way to persist the data on the device. For example, if a salesperson must download his product list every time he opens his application, the time lag required to populate the application with information could be frustrating.

  • Single point of failure

    With this kind of solution, users often rely on a single server database. If that database is not available because of planned server downtime or from server failures, all remote workers will be disconnected from their data.

  • Server scalability

    As more people work remotely, the performance of the corporate servers will be affected, and more hardware might have to be added.

Occasionally Connected Applications

An alternative to the solution described in the previous section is to implement an occasionally connected application. An occasionally connected application still enables a remote worker to access data, but the information that she wants is stored locally. To populate a local database, an occasionally connected application typically uses data synchronization.

Data synchronization consists of the ability to periodically take information that is stored in one database (such as a client database) and synchronize changes with another database (such as a server database). A synchronization-based solution offers the advantage that a user no longer has to have a constant network connection to access information. Because the data is stored locally, a user has constant access to the data while processing is offloaded from the central database. Additionally, because the speed of the network is no longer a limiting factor, a user can now access the data at the speed of the local computer.

Client-to-client synchronization avoids the single point of failure by enabling synchronization that does not rely on all changes going through a server. The ability to push a lot of the application processing to each client also helps to address the issue of server scalability.

Sync Framework uses synchronization providers to communicate with each database that is synchronized. The Sync Framework database providers, which are analogous to ADO.NET data providers, shield other Sync Framework components from the specific implementation of each database. Sync Framework includes five database providers, which support two types of scenarios: offline and collaboration scenarios. The following illustration shows an offline scenario: in a client-server topology, clients connect to a central server to synchronize data when a connection is available.

A common extension to this kind of occasionally connected application is the ability to support collaboration scenarios. These are scenarios in which two databases can be synchronized peer-to-peer without having to go through a central hub. The following illustration shows a mixed topology in which a central server synchronizes with clients, and the clients are able to synchronize with each other. A topology like this could support an application that allows users to share project notes. Project team members often require a local copy of data that they can work with. When they have made changes, they can synchronize with a server to upload changes or with another team member to exchange changes.

Database Synchronization Providers

The three primary database synchronization providers that Sync Framework includes are suitable for offline and collaboration scenarios within client-server, peer-to-peer, and mixed topologies. These providers can be combined to synchronize with each other in many different ways within your chosen topology. Because they use Sync Framework metadata, they can even synchronize with other Sync Framework providers. The providers are:

For more information about database synchronization, see Database Synchronization Scenarios.

Offline-Only Providers

Two additional database synchronization providers are included that support offline scenarios only. These providers have been superseded by the providers described above that support both offline and collaboration scenarios. They are included in this documentation as reference for existing applications that use them. For developing new applications, please use the providers described above.

The offline-only providers are:

These providers have the following characteristics:

  • Suitable for client-server topologies.

  • Always used as a pair. For example, you cannot synchronize two server databases by using two instances of ServerSyncProvider (use SqlSyncProvider or DbSyncProvider instead).

  • Can be less complex than the collaboration providers, but they cannot participate in topologies with other Sync Framework providers.

For more information about offline synchronization, see Offline-Only Scenarios.

請參閱

概念

Synchronizing Databases