G->TechLink: G->Pointer's Technology Link

Transactional replication typically starts with a snapshot of the publication database objects and data. As soon as the initial snapshot is taken, subsequent data changes and schema modifications made at the Publisher are usually delivered to the Subscriber as they occur (in near real time). The data changes are applied to the Subscriber in the same order and within the same transaction boundaries as they occurred at the Publisher; therefore, within a publication, transactional consistency is guaranteed. Transactional replication is typically used in server-to-server environments and is appropriate in each of the following cases: You want incremental changes to be propagated to Subscribers as they occur. The application requires low latency between the time changes are made at the Publisher and the changes arrive at the Subscriber. The application requires access to intermediate data states. For example, if a row changes five times, transactional replication allows an applic...

Merge replication, like transactional replication, typically starts with a snapshot of the publication database objects and data. Subsequent data changes and schema modifications made at the Publisher and Subscribers are tracked with triggers. The Subscriber synchronizes with the Publisher when connected to the network and exchanges all rows that have changed between the Publisher and Subscriber since the last time synchronization occurred. Merge replication is typically used in server-to-client environments. Merge replication is appropriate in any of the following situations: Multiple Subscribers might update the same data at various times and propagate those changes to the Publisher and to other Subscribers. Subscribers need to receive data, make changes offline, and later synchronize changes with the Publisher and other Subscribers. Each Subscriber requires a different partition of data. Conflicts might occur and, when they do, you need the ability to detect and resolve th...