Replication

Table of Contents
Replication
What's New (Replication)
Replication Backward Compatibility
Deprecated Features in SQL Server Replication
Breaking Changes in SQL Server Replication
Replication Areas
Administration of Replication
Replication Agents
Developer Concepts
Monitoring Replication
Non-SQL Heterogeneous Database Replication
Publish Data and Database Objects
Security for Replication
Replication Features and Tasks
Types of Replication
Snapshot Replication
Merge Replication
Transactional Replication
Replication to Memory-Optimized Table Subscribers
Replication to SQL Database
Republish Data
Replication over the Internet
Publish Data over the Internet Using VPN
Web Synchronization for Merge Replication
Configure IIS for Web Synchronization
Configure IIS 7 for Web Synchronization
Configure Distribution
Configure Publishing and Distribution
View and Modify Distributor and Publisher Properties
Disable Publishing and Distribution
Enable a Database for Replication (SQL Server Management Studio)
Enable a Remote Publisher at a Distributor (SQL Server Management Studio)
Specify the Default Snapshot Location (SQL Server Management Studio)
Set the Distribution Retention Period for Transactional Publications (SQL Server
Management Studio)
Set the History Retention Period (SQL Server Management Studio)
Subscribe to Publications
Create a Pull Subscription
Create a Push Subscription
View and Modify Pull Subscription Properties
View and Modify Push Subscription Properties
Delete a Pull Subscription
Delete a Push Subscription
Subscription Expiration and Deactivation
Create a Subscription for a Non-SQL Server Subscriber
Specify a Merge Subscription Type and Conflict Resolution Priority (SQL Server
Management Studio)
Specify Synchronization Schedules
Initialize a Subscription
Initialize a Subscription with a Snapshot
Initialize a Transactional Subscription Without a Snapshot
Reinitialize Subscriptions
Synchronize Subscriptions (Replication)
Create and Apply the Initial Snapshot
Enable Initialization with a Backup for Transactional Publications (SQL Server
Management Studio)
Initialize a Transactional Subscription from a Backup (Replication Transact-SQL
Programming)
Initialize a Subscription Manually
Synchronize a Pull Subscription
Synchronize a Push Subscription
Reinitialize a Subscription
Execute Scripts Before and After a Snapshot Is Applied (SQL Server Management
Studio)
Execute Scripts During Synchronization (Replication Transact-SQL Programming)
View and Resolve Data Conflicts for Merge Publications (SQL Server Management
Studio)
View Conflict Information for Merge Publications (Replication Transact-SQL
Programming)
View Data Conflicts for Transactional Publications (SQL Server Management Studio)
Synchronize a Subscription Using Windows Synchronization Manager (Windows
Synchronization Manager)
Control the Behavior of Triggers and Constraints During Synchronization (Replication
Transact-SQL Programming)
Implement a Business Logic Handler for a Merge Article
Implement a Custom Conflict Resolver for a Merge Article
Bulk-Load Data into Tables in a Merge Publication (Replication Transact-SQL
Programming)
Synchronize Data
Validate Replicated Data
Validate Partition Information for a Merge Subscriber
Validate Data at the Subscriber
Scripting Replication
Technical Reference
Properties Reference
Distributor Properties
Publisher Properties
Subscriber Properties
Publication Properties - <Publication>
Article Properties - <Article>
Subscription Properties - <Subscription>
Tools Reference
Replication Monitor
Configure Distribution Wizard
New Publication Wizard
New Subscription Wizard (UI Reference)
Configure Peer-to-Peer Topology Wizard
Microsoft Replication Conflict Viewer and Interactive Resolver
SQL Server Management Studio Replication Dialog Boxes
Errors and Events Reference
MSSQL_ENG002601
MSSQL_ENG002627
MSSQL_ENG003165
MSSQL_ENG003724
MSSQL_ENG004929
MSSQL_ENG014005
MSSQL_ENG014010
MSSQL_ENG014114
MSSQL_ENG014117
MSSQL_ENG014120
MSSQL_ENG014121
MSSQL_ENG014144
MSSQL_ENG014150
MSSQL_ENG014151
MSSQL_ENG014152
MSSQL_ENG014157
MSSQL_ENG014160
MSSQL_ENG014161
MSSQL_ENG014162
MSSQL_ENG014163
MSSQL_ENG014164
MSSQL_ENG014165
MSSQL_ENG018456
MSSQL_ENG018752
MSSQL_ENG020554
MSSQL_ENG020557
MSSQL_ENG020572
MSSQL_ENG020574
MSSQL_ENG020575
MSSQL_ENG020596
MSSQL_ENG020598
MSSQL_ENG021075
MSSQL_ENG021076
MSSQL_ENG021286
MSSQL_ENG021330
MSSQL_ENG021331
MSSQL_ENG021385
MSSQL_ENG021797
MSSQL_ENG021798
MSSQL_ENG024070
MSSQL_REPL020011
MSSQL_REPL027056
MSSQL_REPL027183
MSSQL_REPL-2147198698
Replication Language Reference
Replication Tutorials
Preparing the Server for Replication
Lesson 1: Creating Windows Accounts for Replication
Lesson 2: Preparing the Snapshot Folder
Lesson 3: Configuring Distribution
Replicating Data Between Fully Connected Servers
Lesson 1: Publishing Data Using Transactional Replication
Lesson 2: Creating a Subscription to the Transactional Publication
Lesson 3: Validating the Subscription and Measuring Latency
Replicating Data with Mobile Clients
Lesson 1: Publishing Data Using Merge Replication
Lesson 2: Creating a Subscription to the Merge Publication
Lesson 3: Synchronizing the Subscription to the Merge Publication
SQL Server Replication
11/16/2017 1 min to read Edit Online
THIS TOPIC APPLIES TO: SQL Server Azure SQL Database Azure SQL Data Warehouse Parallel Data
Warehouse
Replication is a set of technologies for copying and distributing data and database objects from one database to
another and then synchronizing between databases to maintain consistency. Use replication to distribute data to
different locations and to remote or mobile users over local and wide area networks, dial-up connections, wireless
connections, and the Internet.
Transactional replication is typically used in server-to-server scenarios that require high throughput, including:
improving scalability and availability; data warehousing and reporting; integrating data from multiple sites;
integrating heterogeneous data; and offloading batch processing. Merge replication is primarily designed for
mobile applications or distributed server applications that have possible data conflicts. Common scenarios include:
exchanging data with mobile users; consumer point of sale (POS) applications; and integration of data from
multiple sites. Snapshot replication is used to provide the initial data set for transactional and merge replication; it
can also be used when complete refreshes of data are appropriate. With these three types of replication, SQL
Server provides a powerful and flexible system for synchronizing data across your enterprise. Replication to SQLCE
3.5 and SQLCE 4.0 is supported on both Windows Server 2012 and Windows 8.
As an alternative to replication, you can synchronize databases by using Microsoft Sync Framework. Sync
Framework includes components and an intuitive and flexible API that make it easy to synchronize among SQL
Server, SQL Server Express, SQL Server Compact, and SQL Azure databases. Sync Framework also includes classes
that can be adapted to synchronize between a SQL Server database and any other database that is compatible with
ADO.NET. For detailed documentation of the Sync Framework database synchronization components, see
Synchronizing Databases. For an overview of Sync Framework, see Microsoft Sync Framework Developer Center.
For a comparison between Sync Framework and Merge Replication, see Synchronizing Databases Overview
Browse by area
Whats New
Backward Compatibility
Technical Reference
What's New (Replication)
Warehouse
SQL Server 2016 has not introduced significant new features to SQL Server replication.
SQL Server 2016 does not support replication to or from SQL Server 2005 or SQL Server Compact.
See Also
Features Supported by the Editions of SQL Server 2016
Warehouse
Topics in the backward compatibility section describe changes in behavior between versions of Microsoft SQL
Server replication. It is important to understand backward compatibility if you are upgrading or if you have more
than one version of SQL Server in a replication topology.
Replication features that have been retained in Microsoft SQL Server 2017 for backward compatibility, but which
will be removed in a future version of SQL Server.
Replication feature changes that might require changes to applications.
See Also
Upgrade Replicated Databases
Warehouse
This topic describes the deprecated Replication features that are still available in SQL Server 2017. These features
are scheduled to be removed in a future release of SQL Server. Deprecated features should not be used in new
applications.
Items Deprecated in SQL Server 2016

FEATURE DESCRIPTION
SQL Server 2008 Replication is supported if each SQL Server endpoint is within
two major versions of the current version of SQL Server.
Consequently, SQL Server 2016 does not support replication
to or from SQL Server 2008 or SQL Server 2008 R2.
SQL Server Compact Replication is supported if each SQL Server endpoint is within
two major versions of the current version of SQL Server.
Consequently, SQL Server 2016 does not support replication
to or from SQL Server Compact.
See Also
Warehouse
This topic describes breaking changes in SQL Server Replication. These changes might break applications, scripts,
or functionalities that are based on earlier versions of SQL Server. You might encounter these issues when you
upgrade.
Breaking Changes Made in SQL Server 2016

SQL Server 2016 does not support replication to or from SQL Server 2005 or SQL Server Compact.
See Also
Administration (Replication)
Warehouse
This section contains information on administering replication topologies. We recommend that you read the best
practices topic first, and then follow the links from that topic to more detailed information in this section and other
sections.
In This Section
Best Practices for Replication Administration
Describes a variety of best practices, including information about backup and restore, monitoring, performance,
and maintenance tasks.
Frequently Asked Questions for Replication Administrators
Addresses a wide variety of questions related to administrative tasks and how replication functions.
Maintain Publications
Describes how to add and drop articles from publications and provides a list of property changes that require
reinitialization or the generation of a new snapshot.
Replication Agent Administration
Provides information on replication agents, agent profiles, and using alerts.
Back Up and Restore Replicated Databases
Details considerations for backing up and restoring replicated databases, with strategies for each type of
replication.
Provides information on validating data at Subscribers to determine whether the data matches the data at the
Publisher.
See Also
Monitoring (Replication)
Replication Agents
Warehouse
Replication uses many stand-alone programs, which are named "agents," to perform the tasks associated with
tracking changes and distributing data. This section of the documentation contains parameter references for the
following replication agents.
In This Section
Replication Agents Overview
Replication Distribution Agent
Replication Log Reader Agent
Replication Merge Agent
Replication Queue Reader Agent
Replication Snapshot Agent
Replication Developer Documentation
Warehouse
The ability to programmatically configure, maintain, and monitor a replication topology enables you to both
simplify repeated replication tasks and improve the user experience for your replication-based applications. By
programming replication, your end-users can be provided with customized replication functionalities without
having to be familiar with replication stored procedures and replication agent executables or having to using the
replication user interface implemented by SQL Server Management Studio.
The following are scenarios in which your applications might benefit from programmatic access to replication
services:
Adding replication functionalities to an existing end-user application, such as synchronizing a pull
subscription when the user clicks a button.
Creating a Web-based user interface for remotely administering replication.
Creating a custom user interface that exposes only a subset of administration functionality, can be used to
remotely administer multiple replication topologies from a single location, or that combine administration
and synchronization functionalities.
Improving an existing monitoring tool by adding the ability to monitor the status of a publication,
subscription, or at the Distributor.
Creating a custom application to administer or synchronize subscriptions to an Oracle publisher.
Writing customized business rules that are executed when a merge subscription is synchronized.
Generating Transact-SQL scripts that can be run repeated when configuring new Subscribers.
SQL Server enables you to programmatically control replication agents and to programmatically administer
and monitor a replication topology. To learn more about programming replication, see Replication
Programming Concepts.
In This Section
Replication Programming Concepts
Describes the planning steps to develop an application that uses replication.
Replication System Stored Procedures Concepts
Describes how system stored procedures can be used to proivide programmatic access in a replication topology.
Replication Management Objects Concepts
Explains the concepts for using Replication Management Objects (RMO). This is a managed code assembly that
encapsulates replication functionalities for SQL Server.
Replication Agent Executables Concepts
Describes the use of Replication Agent Executable files.
Developer's Guide: How-to Topics (Replication)
Provides a list of how-to topics that are related to replication.
Warehouse
Monitoring a replication topology is an important aspect of deploying replication. Because replication activity is
distributed, it is essential to track activity and status across all computers involved in replication. The following
tools can be used to monitor replication:
Microsoft SQL Server Replication Monitor
Replication Monitor is the most important tool for monitoring replication, presenting a Publisher-focused
view of all replication activity. For more information, see Monitoring Replication.
Microsoft SQL Server Management Studio
Management Studio provides access to Replication Monitor. It also allows you to view the current status
and last message logged by the following agents and allows you start and stop each agent: Log Reader
Agent, Snapshot Agent, Merge Agent, and Distribution Agent. For more information, see Monitor
Replication Agents.
Transact-SQL and Replication Management Objects (RMO)
Both interfaces allow you to monitor all types of replication from the Distributor. Merge replication also
provides the ability to monitor replication from the Subscriber.
Alerts for replication agent events
Replication provides a number of predefined alerts for replication agent events, and you can create
additional alerts if necessary. Alerts can be used to trigger an automated response to an event and/or notify
an administrator. For more information, see Use Alerts for Replication Agent Events.
System Monitor
System Monitor can be useful for monitoring performance, providing a number of counters for replication.
For more information, see Monitoring Replication with System Monitor.
See Also
Heterogeneous Database Replication
Warehouse
SQL Server supports the following heterogeneous scenarios for transactional and snapshot replication:
Publishing data from SQL Server to non- SQL Server Subscribers.
Publishing data to and from Oracle has the following restrictions:
2016 OR EARLIER 2017 OR LATER
Replication from Oracle Only support Oracle 10g or earlier Only support Oracle 10g or earlier
Replication to Oracle Up to Oracle 12c Not supported
Heterogeneous replication to non-SQL Server subscribers is deprecated. Oracle Publishing is deprecated. To move
data, create solutions using change data capture and SSIS.
Cau t i on
This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new
development work, and plan to modify applications that currently use this feature.
Publishing Data from Oracle

You can use SQL Server to publish data from Oracle with most of the same features and ease-of-use as SQL Server
snapshot and transactional replication. This feature requires Oracle version 10G or earlier. Publishing data from
Oracle is ideal for the following scenarios:
SCENARIO DESCRIPTION
Microsoft .NET Framework application deployments Develop with Microsoft Visual Studio and SQL Server while
operating on data replicated from a non- SQL Server
database.
Data warehousing staging servers Keep SQL Server staging databases synchronized with a non-
SQL Server database.
Migration to SQL Server Test your application in real time against SQL Server while
replicating the source system's changes. Switch to SQL Server
when satisfied with the migration.
For more information, see Oracle Publishing Overview.
Publishing Data to Non-SQL Server Subscribers

The following non- SQL Server databases are supported as Subscribers to snapshot and transactional publications:
Oracle for all platforms that Oracle supports.
IBM DB2 for AS400, MVS, Unix, Linux, and Windows.
For more information, see Non-SQL Server Subscribers.
THIS TOPIC APPLIES TO: SQL Server Azure SQL Database Azure SQL Data Warehouse Parallel
Data Warehouse
When creating a publication, you choose the tables and other database objects that you want to publish. You
can publish the following database objects using replication.
SNAPSHOT REPLICATION AND

DATABASE OBJECT TRANSACTIONAL REPLICATION MERGE REPLICATION
Tables X X
Partitioned Tables X X
Stored Procedures Definition ( X X

Transact-SQL and CLR)
Stored Procedures Execution ( X no

Transact-SQL and CLR)
Views X X
Indexed Views X X
Indexed Views as Tables X no
User-Defined Types (CLR) X X
User-Defined Functions ( Transact- X X

SQL and CLR)
Alias Data Types X X
Full text indexes X X
Schema Objects (constraints, indexes, X X

user DML triggers, extended
properties, and collation)
Creating Publications
To create a publication, you supply the following information:
The Distributor.
The location of the snapshot files.
The publication database.
The type of publication to create (snapshot, transactional, transactional with updatable subscriptions, or
merge).
The data and database objects (articles) to include in the publication.
Static row filters and column filters for all types of publications, and parameterized row filters and join
filters for merge publications.
The Snapshot Agent schedule.
Accounts under which the following agents will run: the Snapshot Agent for all publications; the Log
Reader Agent for all transactional publications; the Queue Reader Agent for transactional publications
that allow updating subscriptions.
A name and description for the publication.
For information about how to work with publications, see the following topics:
Create a Publication
Define an Article
View and Modify Publication Properties
View and Modify Article Properties
Delete a Publication
Delete an Article
NOTE
Deleting an article or publication does not remove objects from the Subscriber.
Publishing Tables
The most commonly published object is a table. The following links provide additional information about areas
related to publishing tables:
Filter Published Data
Article Options for Transactional Replication
Article Options for Merge Replication
Replicate Identity Columns
When publishing a table for replication, you can specify which schema objects should be copied to the
Subscriber, such as declared referential integrity (primary key constraints, reference constraints, unique
constraints), indexes, user DML triggers (DDL triggers cannot be replicated), extended properties, and
collation. Extended properties are replicated only in the initial synchronization between the Publisher
and the Subscriber. If you add or modify an extended property after the initial synchronization, the
change is not replicated.
To specify schema options, see Specify Schema Options or SchemaOption.
Partitioned Tables and Indexes
Replication supports the publishing of partitioned tables and indexes. The level of support depends on the type
of replication that is used, and the options that you specify for the publication and the articles associated with
partitioned tables. For more information, see Replicate Partitioned Tables and Indexes.
Publishing Stored Procedures

All types of replication allow you to replicate stored procedure definitions: the CREATE PROCEDURE is copied to
each Subscriber. In the case of common language runtime (CLR) stored procedures, the associated assembly is
also copied. Changes to procedures are replicated to Subscribers; changes to associated assemblies are not.
In addition to replicating the definition of a stored procedure, transactional replication allows you to replicate
the execution of stored procedures. This is useful in replicating the results of maintenance-oriented stored
procedures that affect large amounts of data. For more information, see Publishing Stored Procedure Execution
in Transactional Replication.
Publishing Views
All types of replication allow you to replicate views. The view (and its accompanying index, if it is an indexed
view) can be copied to the Subscriber, but the base table must also be replicated.
For indexed views, transactional replication also allows you to replicate the indexed view as a table rather than
a view, eliminating the need to also replicate the base table. To do this, specify one of the "indexed view
logbased" options for the @type parameter of sp_addarticle (Transact-SQL). For more information about using
sp_addarticle, see Define an Article.
Publishing User-Defined Functions

The CREATE FUNCTION statements for CLR functions and Transact-SQL functions are copied to each
Subscriber. In the case of CLR functions, the associated assembly is also copied. Changes to functions are
replicated to Subscribers; changes to associated assemblies are not.
Publishing User-Defined Types and Alias Data Types

Columns that use user-defined types or alias data types are replicated to Subscribers like other columns. The
CREATE TYPEstatement for each replicated type is executed at the Subscriber before the table is created. In the
case of user-defined types, the associated assembly is also copied to each Subscriber. Changes to user-defined
types and alias data types are not replicated to Subscribers.
If a type is defined in a database, but it is not referenced in any columns when a publication is created, the type
is not copied to Subscribers. If you subsequently create a column of that type in the database and want to
replicate it, you must first manually copy the type (and the associated assembly for a user-defined type) to each
Subscriber.
Publishing Full Text Indexes

The CREATE FULLTEXT INDEX statement is copied to each Subscriber, and the full text index is created at the
Subscriber. Changes made to full text indexes using ALTER FULLTEXT INDEX are not replicated.
Making Schema Changes to Published Objects

Replication supports a wide range of schema changes to published objects. When you make any of the
following schema changes on the appropriate published object at a SQL Server Publisher, that change is
propagated by default to all SQL Server Subscribers:
ALTER TABLE
ALTER VIEW
ALTER PROCEDURE
ALTER FUNCTION
ALTER TRIGGER
For more information, see Make Schema Changes on Publication Databases.
Considerations for Publishing

Keep the following issues in mind when publishing database objects:
The database is accessible to users during the creation of the publication and the initial snapshot, but it is
advisable to create publications during times of lower activity on the Publisher.
A database cannot be renamed after a publication is created in it. To rename it, you must first remove
replication from the database.
If you are publishing a database object that depends on one or more other database objects, you must
publish all referenced objects. For example, if you publish a view that depends on a table, you must
publish the table also.
NOTE
If you add an article to a merge publication and an existing article depends on the new article, you must specify a
processing order for both articles using the @processing_order parameter of sp_addmergearticle and
sp_changemergearticle. Consider the following scenario: you publish a table but you do not publish a function
that the table references. If you do not publish the function, the table cannot be created at the Subscriber. When
you add the function to the publication: specify a value of 1 for the @processing_order parameter of
sp_addmergearticle; and specify a value of 2 for the @processing_order parameter of
sp_changemergearticle, specifying the table name for the parameter @article. This processing order ensures
that you create the function at the Subscriber before the table that depends on it. You can use different numbers
for each article as long as the number for the function is lower than the number for the table.
Publication names cannot include the following characters: % * [ ] | : " ? \ / < >.
Limitations on Publishing Objects
The maximum number of articles and columns that can be published differs by publication type. For
more information, see the "Replication Objects" section of Maximum Capacity Specifications for SQL
Server.
Stored procedures, views, triggers, and user-defined functions that are defined as WITH ENCRYPTION
cannot be published as part of SQL Server replication.
XML schema collections can be replicated but changes are not replicated after the initial snapshot.
Tables published for transactional replication must have a primary key. If a table is in a transactional
replication publication, you cannot disable any indexes that are associated with primary key columns.
These indexes are required by replication. To disable an index, you must first drop the table from the
publication.
Bound defaults created with sp_bindefault (Transact-SQL) are not replicated (bound defaults are
deprecated in favor of defaults created with the DEFAULT keyword of ALTER TABLE or CREATE TABLE).
Functions containing the NOEXPAND hint on indexed views cannot be published in the same
publication as the referenced tables and indexed views, due to the order in which the distribution agent
delivers them. To work around this problem, place the table and indexed view creation in a first
publication, and add functions containing the NOEXPAND hint on the indexed views to a second
publication which you publish after the first publication completes. Or, create scripts for these functions
and deliver the script by using the @post_snapshot_script parameter of sp_addpublication.
Schemas and Object Ownership
Replication has the following default behavior in the New Publication Wizard with respect to schemas and
object ownership:
For articles in merge publications with a compatibility level of 90 or higher, snapshot publications, and
transactional publications: by default, the object owner at the Subscriber is the same as the owner of the
corresponding object at the Publisher. If the schemas that own objects do not exist at the Subscriber,
they are created automatically.
For articles in merge publications with a compatibility level lower than 90: by default, the owner is left
blank and is specified as dbo during the creation of the object on the Subscriber.
For articles in Oracle publications: by default, the owner is specified as dbo.
For articles in publications that use character mode snapshots (which are used for non- SQL Server
Subscribers and SQL Server Compact Subscribers): by default, the owner is left blank. The owner
defaults to the owner associated with the account used by the Distribution Agent or Merge Agent to
connect to the Subscriber.
The object owner can be changed through the Article Properties - <Article> dialog box and through
the following stored procedures: sp_addarticle, sp_addmergearticle, sp_changearticle, and
sp_changemergearticle. For more information, see View and Modify Publication Properties, Define an
Article, and View and Modify Article Properties.
Publishing Data to Subscribers Running Previous Versions of SQL Server
If you are publishing to a Subscriber running a previous version of SQL Server, you are limited to the
functionality of that version, both in terms of replication-specific functionality and the functionality of the
product as a whole.
Merge publications use a compatibility level, which determines what features can be used in a
publication and allows you to support Subscribers running previous versions of SQL Server.
Publishing Tables in More Than One Publication
Replication supports publishing articles in multiple publications (including republishing data) with the
following restrictions:
If an article is published in a transactional publication and a merge publication, ensure that the
@published_in_tran_pub property is set to TRUE for the merge article. For more information about
setting properties, see View and Modify Publication Properties and View and Modify Article Properties.
You should also set the @published_in_tran_pub property if an article is part of a transactional
subscription and is included in a merge publication. If this is the case, be aware that by default
transactional replication expects tables at the Subscriber to be treated as read-only; if merge replication
makes data changes to a table in a transactional subscription, non-convergence of data can occur. To
avoid this possibility, we recommend that any such table be specified as download-only in the merge
publication. This prevents a merge Subscriber from uploading data changes to the table. For more
information, see Optimize Merge Replication Performance with Download-Only Articles.
An article cannot be published in both a merge publication and a transactional publication with queued
updating subscriptions.
Articles included in transactional publications that support updating subscriptions cannot be
republished.
If an article is published in more than one transactional publication that supports queued updating
subscriptions, the following properties must have the same value for the article across all publications:
PROPERTY PARAMETER IN SP_ADDARTICLE
Identity range management @auto_identity_range (deprecated) and

@identityrangemangementoption
Publisher identity range @pub_identity_range
Identity range @identity_range
Identity range threshold @threshold
For more information about these parameters, see sp_addarticle (Transact-SQL).

If an article is published in more than one merge publication, the following properties must have the
same value for the article across all publications:
PROPERTY PARAMETER IN SP_ADDMERGEARTICLE
Column tracking @column_tracking
Schema options @schema_option
Column filtering @vertical_partition
Subscriber upload options @subscriber_upload_options
Conditional delete tracking @delete_tracking
Error compensation @compensate_for_errors
Identity range management @auto_identity_range (deprecated) and

@identityrangemangementoption
Publisher identity range @pub_identity_range
Identity range @identity_range
Identity range threshold @threshold
Partition options @partition_options
Blob column streaming @stream_blob_columns
Filter type @filter_type (parameter in sp_addmergefilter)
For more information about these parameters, see sp_addmergearticle (Transact-SQL) and
sp_addmergefilter (Transact-SQL).
Transactional replication and unfiltered merge replication support publishing a table in multiple
publications and then subscribing within a single table in the subscription database (commonly referred
to as a roll up scenario). Roll up is often used for aggregating subsets of data from multiple locations in
one table at a central Subscriber. Filtered merge publications do not support the central Subscriber
scenario. For merge replication, roll up is typically implemented through a single publication with
parameterized row filters. For more information, see Parameterized Row Filters.
See Also
Add Articles to and Drop Articles from Existing Publications
Secure the Publisher
Security Overview (Replication)
Warehouse
Fundamentally, how to help secure your replication environment is a matter of understanding the authentication
and authorization options, understanding appropriate uses of replication filtering features, and learning specific
measures for how to help secure each piece of the replication environment. The replication environment includes
the Distributor, Publisher, Subscribers, and the snapshot folder. This chapter addresses replication security, but
replication security is built on SQL Server security and Windows security. Therefore, you should understand this
foundation and the specifics of replication security. For more information about security, see Security
Considerations for a SQL Server Installation. For more information about security considerations for Oracle
publishing, see the section "Replication Security Model" in the topic Design Considerations and Limitations for
Oracle Publishers.
In This Section
Threat and Vulnerability Mitigation (Replication)
Discusses potential threats to a replication topology and describes ways to reduce those threats.
Identity and Access Control (Replication)
Describes how to use authentication, authorization, and filtering to help secure a replication topology.
Secure Development (Replication)
Describes replication security behavior, replication security best practices, and least permissions for replication.
Secure Deployment (Replication)
Describes how to better secure all components of a replication topology
See Also
Security and Protection (Replication)
Warehouse
Find information that anyonedesigner, developer, analyst, or administratorrequires to design and implement
replication solutions.
In This Section
Heterogeneous Database Replication
Replication Agents
Republish Data
Interoperability of Replication and High Availability Features

Configure Replication for Always On Availability Groups (SQL Server)
Maintaining an Always On Publication Database (SQL Server)
Replication, Change Tracking, Change Data Capture, and Always On Availability Groups (SQL Server)
Log Shipping and Replication (SQL Server)
Database Mirroring and Replication (SQL Server)
See Also
SQL Server Replication
Technical Reference (Replication)
Warehouse
Microsoft SQL Server provides the following types of replication for use in distributed applications:
Transactional replication. For more information, see Transactional Replication.
Merge replication. For more information, see Merge Replication.
Snapshot replication. For more information, see Snapshot Replication.
The type of replication you choose for an application depends on many factors, including the physical
replication environment, the type and quantity of data to be replicated, and whether the data is updated at
the Subscriber. The physical environment includes the number and location of computers involved in
replication and whether these computers are clients (workstations, laptops, or handheld devices) or servers.
Each type of replication typically begins with an initial synchronization of the published objects between the
Publisher and Subscribers. This initial synchronization can be performed by replication with a snapshot,
which is a copy of all of the objects and data specified by a publication. After the snapshot is created, it is
delivered to the Subscribers. For some applications, snapshot replication is all that is required. For other
types of applications, it is important that subsequent data changes flow to the Subscriber incrementally over
time. Some applications also require that changes flow from the Subscriber back to the Publisher.
Transactional replication and merge replication provide options for these types of applications.
Data changes are not tracked for snapshot replication; each time a snapshot is applied, it completely
overwrites the existing data. Transactional replication tracks changes through the SQL Server transaction
log, and merge replication tracks changes through triggers and metadata tables.
See Also
Snapshot Replication
Warehouse
Snapshot replication distributes data exactly as it appears at a specific moment in time and does not monitor for
updates to the data. When synchronization occurs, the entire snapshot is generated and sent to Subscribers.
NOTE
Snapshot replication can be used by itself, but the snapshot process (which creates a copy of all of the objects and data
specified by a publication) is also commonly used to provide the initial set of data and database objects for transactional and
merge publications.
Using snapshot replication by itself is most appropriate when one or more of the following is true:
Data changes infrequently.
It is acceptable to have copies of data that are out of date with respect to the Publisher for a period of time.
Replicating small volumes of data.
A large volume of changes occurs over a short period of time.
Snapshot replication is most appropriate when data changes are substantial but infrequent. For example, if a
sales organization maintains a product price list and the prices are all updated at the same time once or
twice each year, replicating the entire snapshot of data after it has changed is recommended. Given certain
types of data, more frequent snapshots may also be appropriate. For example, if a relatively small table is
updated at the Publisher during the day, but some latency is acceptable, changes can be delivered nightly as
a snapshot.
Snapshot replication has a lower continuous overhead on the Publisher than transactional replication,
because incremental changes are not tracked. However, if the dataset set being replicated is very large, it will
require substantial resources to generate and apply the snapshot. Consider the size of the entire data set
and the frequency of changes to the data when evaluating whether to utilize snapshot replication.
In this topic
How Snapshot Replication Works
Snapshot Agent
Distribution and Merge Agents
How Snapshot Replication Works

By default, all three types of replication use a snapshot to initialize Subscribers. The SQL Server Snapshot Agent
always generates the snapshot files, but the agent that delivers the files differs depending on the type of replication
being used. Snapshot replication and transactional replication use the Distribution Agent to deliver the files,
whereas merge replication uses the SQL Server Merge Agent. The Snapshot Agent runs at the Distributor. The
Distribution Agent and Merge Agent run at the Distributor for push subscriptions, or at Subscribers for pull
subscriptions.
Snapshots can be generated and applied either immediately after the subscription is created or according to a
schedule set at the time the publication is created. The Snapshot Agent prepares snapshot files containing the
schema and data of published tables and database objects, stores the files in the snapshot folder for the Publisher,
and records tracking information in the distribution database on the Distributor. You specify a default snapshot
folder when you configure a Distributor, but you can specify an alternate location for a publication instead of or in
addition to the default.
In addition to the standard snapshot process described in this topic, a two-part snapshot process is used for merge
publications with parameterized filters.
The following illustration shows the principal components of snapshot replication.
Snapshot Agent
For merge replication, a snapshot is generated every time the Snapshot Agent runs. For transactional replication,
snapshot generation depends on the setting of the publication property immediate_sync. If the property is set to
TRUE (the default when using the New Publication Wizard), a snapshot is generated every time the Snapshot Agent
runs, and it can be applied to a Subscriber at any time. If the property is set to FALSE (the default when using
sp_addpublication), the snapshot is generated only if a new subscription has been added since the last Snapshot
Agent run; Subscribers must wait for the Snapshot Agent to complete before they can synchronize.
The Snapshot Agent performs the following steps:
1. Establishes a connection from the Distributor to the Publisher, and then takes locks on published tables if
necessary:
For merge publications, the Snapshot Agent does not take any locks.
For transactional publications, by default the Snapshot Agent take locks only during the initial phase
of snapshot generation.
For snapshot publications, locks are held during the entire snapshot generation process.
2. Writes a copy of the table schema for each article to a .sch file. If other database objects are published, such
as indexes, constraints, stored procedures, views, user-defined functions, and so on, additional script files are
generated.
3. Copies the data from the published table at the Publisher and writes the data to the snapshot folder. The
snapshot is generated as a set of bulk copy program (BCP) files.
4. For snapshot and transactional publications, the Snapshot Agent appends rows to the MSrepl_commands
and MSrepl_transactions tables in the distribution database. The entries in the MSrepl_commands table
are commands indicating the location of .sch and .bcp files, any other snapshot files, and references to any
pre- or post-snapshot scripts. The entries in the MSrepl_transactions table are commands relevant to
synchronizing the Subscriber.
For merge publications, the Snapshot Agent performs additional steps.
5. Releases any locks on published tables.
During snapshot generation, you cannot make schema changes on published tables. After the snapshot files
are generated, you can view them in the snapshot folder using Windows Explorer.
Distribution Agent and Merge Agent

For snapshot publications, each time the Distribution Agent runs for the publication, it moves a new snapshot to
each Subscriber that has not yet been synchronized, has been marked for reinitialization, or includes new articles.
For snapshot and transactional replication, the Distribution Agent performs the following steps:
1. Establishes a connection to the Distributor.
2. Examines the MSrepl_commands and MSrepl_transactions tables in the distribution database on the
Distributor. The agent reads the location of the snapshot files from the first table and Subscriber
synchronization commands from both tables.
3. Applies the schema and commands to the subscription database.
For an unfiltered merge replication publication, the Merge Agent performs the following steps:
4. Establishes a connection to the Publisher.
5. Examines the sysmergeschemachange table on the Publisher and determines whether there is a new
snapshot that should be applied at the Subscriber.
6. If a new snapshot is available, the Merge Agent applies to the subscription database the snapshot files from
the location specified in sysmergeschemachange.
Merge Replication
Warehouse
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 them.
The application requires net data change rather than access to intermediate data states. For example, if a
row changes five times at a Subscriber before it synchronizes with a Publisher, the row will change only
once at the Publisher to reflect the net data change (that is, the fifth value).
Merge replication allows various sites to work autonomously and later merge updates into a single, uniform
result. Because updates are made at more than one node, the same data may have been updated by the
Publisher and by more than one Subscriber. Therefore, conflicts can occur when updates are merged and
merge replication provides a number of ways to handle conflicts.
Merge replication is implemented by the SQL Server Snapshot Agent and Merge Agent. If the publication is
unfiltered or uses static filters, the Snapshot Agent creates a single snapshot. If the publication uses
parameterized filters, the Snapshot Agent creates a snapshot for each partition of data. The Merge Agent
applies the initial snapshots to the Subscribers. It also merges incremental data changes that occurred at the
Publisher or Subscribers after the initial snapshot was created, and detects and resolves any conflicts
according to rules you configure.
To track changes, merge replication (and transactional replication with queued updating subscriptions) must
be able to uniquely identify every row in every published table. To accomplish this merge replication adds
the column rowguid to every table, unless the table already has a column of data type uniqueidentifier
with the ROWGUIDCOL property set (in which case this column is used). If the table is dropped from the
publication, the rowguid column is removed; if an existing column was used for tracking, the column is not
removed. A filter must not include the rowguidcol used by replication to identify rows. The newid()
function is provided as a default for the rowguid column, however customers can provide a guid for each
row if needed. However, do not provide value 00000000-0000-0000-0000-000000000000.
The following diagram shows the components used in merge replication.
Warehouse
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 application to respond to each change (such as firing a trigger), not
simply the net data change to the row.
The Publisher has a very high volume of insert, update, and delete activity.
The Publisher or Subscriber is a non- SQL Server database, such as Oracle.
By default, Subscribers to transactional publications should be treated as read-only, because changes are not
propagated back to the Publisher. However, transactional replication does offer options that allow updates
at the Subscriber.
In This Topic
How Transactional Replication Works
Initial Dataset
Snapshot Agent
Log Reader Agent
Distribution Agent
How Transactional Replication Works

Transactional replication is implemented by the SQL Server Snapshot Agent, Log Reader Agent, and Distribution
Agent. The Snapshot Agent prepares snapshot files containing schema and data of published tables and database
objects, stores the files in the snapshot folder, and records synchronization jobs in the distribution database on the
Distributor.
The Log Reader Agent monitors the transaction log of each database configured for transactional replication and
copies the transactions marked for replication from the transaction log into the distribution database, which acts as
a reliable store-and-forward queue. The Distribution Agent copies the initial snapshot files from the snapshot
folder and the transactions held in the distribution database tables to Subscribers.
Incremental changes made at the Publisher flow to Subscribers according to the schedule of the Distribution Agent,
which can run continuously for minimal latency, or at scheduled intervals. Because changes to the data must be
made at the Publisher (when transactional replication is used without immediate updating or queued updating
options), update conflicts are avoided. Ultimately, all Subscribers will achieve the same values as the Publisher. If
immediate updating or queued updating options are used with transactional replication, updates can be made at
the Subscriber, and with queued updating, conflicts might occur.
The following illustration shows the principal components of transactional replication.
Initial Dataset
Before a new transactional replication Subscriber can receive incremental changes from a Publisher, the Subscriber
must contain tables with the same schema and data as the tables at the Publisher. The initial dataset is typically a
snapshot that is created by the Snapshot Agent and distributed and applied by the Distribution Agent. The initial
dataset can also be supplied through a backup or other means, such as SQL Server Integration Services.
When snapshots are distributed and applied to Subscribers, only those Subscribers waiting for initial snapshots are
affected. Other Subscribers to that publication (those that have already been initialized) are unaffected.
Concurrent Snapshot Processing

Snapshot replication places shared locks on all tables published as part of replication for the duration of snapshot
generation. This can prevent updates from being made on the publishing tables. Concurrent snapshot processing,
the default with transactional replication, does not hold the share locks in place during the entire snapshot
generation, which allows users to continue working uninterrupted while replication creates initial snapshot files.
Snapshot Agent
The procedures by which the Snapshot Agent implements the initial snapshot in transactional replication are the
same procedures used in snapshot replication (except as outlined above with regard to concurrent snapshot
processing).
After the snapshot files have been generated, you can view them in the snapshot folder using Microsoft Windows
Explorer.
Modifying Data and the Log Reader Agent

The Log Reader Agent runs at the Distributor; it typically runs continuously, but can also run according to a
schedule you establish. When executing, the Log Reader Agent first reads the publication transaction log (the same
database log used for transaction tracking and recovery during regular SQL Server Database Engine operations)
and identifies any INSERT, UPDATE, and DELETE statements, or other modifications made to the data in
transactions that have been marked for replication. Next, the agent copies those transactions in batches to the
distribution database at the Distributor. The Log Reader Agent uses the internal stored procedure sp_replcmds to
get the next set of commands marked for replication from the log. The distribution database then becomes the
store-and-forward queue from which changes are sent to Subscribers. Only committed transactions are sent to the
distribution database.
After the entire batch of transactions has been written successfully to the distribution database, it is committed.
Following the commit of each batch of commands to the Distributor, the Log Reader Agent calls sp_repldone to
mark where replication was last completed. Finally, the agent marks the rows in the transaction log that are ready
to be purged. Rows still waiting to be replicated are not purged.
Transaction commands are stored in the distribution database until they are propagated to all Subscribers or until
the maximum distribution retention period has been reached. Subscribers receive transactions in the same order in
which they were applied at the Publisher.
Distribution Agent
The Distribution Agent runs at the Distributor for push subscriptions and at the Subscriber for pull subscriptions.
The agent moves transactions from the distribution database to the Subscriber. If a subscription is marked for
validation, the Distribution Agent also checks whether data at the Publisher and Subscriber match.
Warehouse
Tables acting as snapshot and transactional replication subscribers, excluding Peer-to-peer transactional
replication, can be configured as memory-optimized tables. Other replication configurations are not compatible
with memory-optimized tables. This feature is available beginning with SQL Server 2016.
Two configurations are required

Configure the subscriber database to support replication to memory-optimized tables
Set the @memory_optimized property to true, by using sp_addsubscription (Transact-SQL) or
sp_changesubscription (Transact-SQL).
Configure the article to support replication to memory-optimized tables
Set the @schema_option = 0x40000000000 option for the article by using sp_addarticle (Transact-SQL) or
sp_changearticle (Transact-SQL).
To configure a memory-optimized table as a subscriber
1. Create a transactional publication. For more information, see Create a Publication.
2. Add articles to the publication. For more information, see Define an Article.
If configuring by using Transact-SQL set the @schema_option parameter of the sp_addarticle stored
procedure to
0x40000000000.
3. In the article properties window set Enable Memory optimization to true.
4. Start the Snapshot Agent job to generate the initial snapshot for this publication. For more information, see
Create and Apply the Initial Snapshot.
5. Now create a new subscription. In the New Subscription Wizard set Memory Optimized Subscription
to true.
Memory-optimized tables should now start receiving updates from the publisher.
Reconfigure an existing transaction replication
1. Go to subscription properties in Management Studio and set Memory Optimized Subscription to true.
The changes are not applied until the subscription is reinitialized.
If configuring by using Transact-SQL set the new @memory_optimized parameter of the
sp_addsubscription stored procedure to true.
2. Go to the article properties for a publication in Management Studio and set Enable Memory optimization
to true.
procedure to
0x40000000000.
3. Memory optimized tables do not support clustered indexes. To have replication handle this by converting it
to nonclustered index on the destination, set Convert clustered index to nonclustered for memory
optimized article to true.
procedure to 0x0000080000000000.
4. Regenerate the snapshot.
5. Reinitialize the Subscription.
Remarks and Restrictions

Only one-way transactional replication is supported. Peer-to-peer transactional replication is not supported.
Memory-optimized tables cannot be published.
Replication tables on the distributor cannot be configured as memory-optimized tables.
Merge replication cannot include memory-optimized tables.
At the subscriber, tables involved in transactional replication can be configured as memory optimized tables, but
the subscriber tables must meet the requirements of memory-optimized tables. This requires the following
restrictions.
Tables replicated to memory-optimized tables on a subscriber are limited to the data types permitted in
memory-optimized tables. For more information, see Supported Data Types for In-Memory OLTP.
Not all Transact-SQL features are supported with memory-optimized tables. See Transact-SQL Constructs
Not Supported by In-Memory OLTP for details.
Modifying a schema file

If using the memory-optimized table option DURABILITY = SCHEMA_AND_DATA the table must have a
nonclustered primary key index.
ANSI_PADDING must be ON.
See Also
Warehouse
SQL Server replication can be configured to Azure SQL Database.
Supported Configurations:
-- The SQL Server can be an instance of SQL Server running on-premises or an instance of SQL Server running
in an Azure virtual machine in the cloud. For more information, see SQL Server on Azure Virtual Machines
overview.
-- SQL Database must be a push subscriber of a SQL Server publisher.
-- The distribution database and the replication agents cannot be placed on SQL Database.
-- Snapshot and one-way transactional replication are supported. Peer-to-peer transactional replication and
merge replication are not supported.
-## Versions
The publisher and distributor must be at least at one of the following versions:
-- SQL Server 2016
-- SQL Server 2014 SP1 CU3
-- SQL Server 2014 RTM CU10
-- SQL Server 2012 SP2 CU8
-- SQL Server 2012 expected in SP3
Attempting to configure replication using an older version can result in error number MSSQL_REPL20084 (The
process could not connect to Subscriber.) and MSSQL_REPL40532 (Cannot open server <name> requested by
the login. The login failed.).
The SQL Database subscriber must be at least V12 and can be in any region.
To use all the features of SQL Database you must be using the latest versions of SQL Server Management
Studio and SQL Server Data Tools.
-## Remarks
Replication can be configured by using SQL Server Management Studio or by executing Transact-SQL
statements on the publisher. You cannot configure replication by using the SQL Database portal.
Replication can only use SQL Server authentication logins to connect to SQL Database.
Replicated table must have a primary key.
You must have an existing Azure subscription and an existing SQL Database V12.
A single publication on SQL Server can support both SQL Database and SQL Server (on-premises and SQL
Server in an Azure virtual machine) subscribers.
Replication management, monitoring, and troubleshooting must be performed from the on-premises SQL
Server.
Only push subscriptions to SQL Database are supported.
Only @subscriber_type = 0 is supported in sp_addsubscription for SQL Database.
SQL Database does not support bi-directional, immediate, updatable, or peer to peer replication.
-## Replication Architecture
-## Scenarios
-#### Typical Replication Scenario
-1. Create a transactional replication publication on an on-premises SQL Server database.
-2. On the on-premises SQL Server use the New Subscription Wizard or Transact-SQL statements to create a
push to subscription to SQL Database.
-3. The initial data set is typically a snapshot that is created by the Snapshot Agent and distributed and applied
by the Distribution Agent. The initial data set can also be supplied through a backup or other means, such as
SQL Server Integration Services.
-#### Data Migration Scenario
-1. Use transactional replication to replicate data from an on-premises SQL Server database to SQL Database.
-2. Redirect the client or middle-tier applications to update the SQL Database copy.
-3. Stop updating the SQL Server version of the table and remove the publication.
-## Limitations
The following options are not supported for SQL Database subscriptions:
-- Copy file groups association
-- Copy table partitioning schemes
-- Copy index partitioning schemes
-- Copy user defined statistics
-- Copy default bindings
-- Copy rule bindings
-- Copy fulltext indexes
-- Copy XML XSD
-- Copy XML indexes
-- Copy permissions
-- Copy spatial indexes
-- Copy filtered indexes
-- Copy data compression attribute
-- Copy sparse column attribute
-- Convert filestream to MAX data types
-- Convert hierarchyid to MAX data types
-- Convert spatial to MAX data types
-- Copy extended properties
-- Copy permissions
Limitations to be determined:
-- Copy collation
-- Execution in a serialized transaction of the SP
-## Examples
Create a publication and a push subscription. For more information, see:
-- Create a Publication
-- Create a Push Subscription by using the Azure SQL Database logical server name as the subscriber (for
example N'azuresqldbdns.database.windows.net') and the SQL Database name as the destination database
(for example AdventureWorks).
-## See Also
Republish Data
Warehouse
In a republishing model, the Publisher sends data to a Subscriber, which then republishes the data to any number
of other Subscribers. This is useful when a Publisher must send data to Subscribers over a slow or expensive
communications link. If there are a number of Subscribers on the far side of that link, using a republisher shifts the
bulk of the distribution load to that side of the link.
Republishing data involves the following steps:
1. Create a publication at the Publisher.
2. Create a subscription to the publication for the republishing Subscriber.
3. Initialize the subscription. The subscription must be initialized before the publication is created at the
republishing Subscriber, or replication will fail.
4. Create a publication in the subscription database at the republishing Subscriber.
5. Create subscriptions to the publication at the republishing Subscriber for the other Subscribers.
6. Initialize the subscriptions.
NOTE
If you use merge replication in a republishing topology, all republishing Subscribers must use server subscriptions. For more
information about subscription types, see Subscribe to Publications.
In the following illustration, both the Publisher and the republisher are acting as their own local Distributors. If each
were set up to use a remote Distributor, each Distributor would need to be on the same side of the slow or
expensive communications link as its Publisher. Publishers must be connected to remote Distributors by reliable,
high-speed communications links.
Any server can act as both a Publisher and Subscriber. For example, consider the following diagram in which a
publication of a table exists in London and must be distributed to four different cities in the United States: Chicago,
New York, San Diego, and Seattle. The server in New York is chosen to subscribe to the published table originating
in London, because the New York site meets these conditions:
The network link back to London is relatively reliable.
The London-to-New York communication costs are acceptable.
There are good network communications lines from New York to all other Subscriber sites in the United
States.
Replication supports the republishing scenarios shown in the following table.
PUBLISHER PUBLISHING SUBSCRIBER SUBSCRIBER
Transactional publication Transactional subscription/transactional Transactional subscription

publication
Transactional publication Transactional subscription/merge Merge subscription

publication*
Merge publication Merge subscription/merge publication Merge subscription
Merge publication Merge subscription/transactional Transactional subscription

publication
*You should set the @published_in_tran_pub property on the merge publication. By default, transactional
replication expects tables at the Subscriber to be treated as read-only. If merge replication makes data changes to a
table in a transactional subscription, non-convergence of data can occur. To avoid this risk, we recommend that any
such table be specified as download-only in the merge publication. This prevents a merge Subscriber from
uploading data changes to the table. For more information, see Optimize Merge Replication Performance with
Download-Only Articles.
See Also
Synchronize Data
Warehouse
Replicating data over the Internet allows remote, disconnected users to access data when they need it using a
connection to the Internet. Replicate data over the Internet using:
A Virtual Private Network (VPN). For more information, see Publish Data over the Internet Using VPN.
The Web synchronization option for merge replication. For more information, see Web Synchronization for
Merge Replication.
All types of Microsoft SQL Server replication can replicate data over a VPN, but you should consider Web
synchronization if you are using merge replication.
Publish Data over the Internet Using VPN
Warehouse
Virtual Private Networking (VPN) technology allows users working at home, branch offices, remote clients, and
other companies to connect to a corporate network over the Internet, while maintaining secure communications.
Users can use Windows Authentication as though they were on a Local Area Network (LAN). All types of Microsoft
SQL Server replication can replicate data over a VPN, but consider using Web synchronization if you are using
merge replication, because Web synchronization eliminates the need for a VPN. For more information, see Web
Synchronization for Merge Replication.
A VPN includes client software so that computers connect over the Internet (or in special cases, even an intranet) to
software in a dedicated computer or a server. Optionally, encryption at both ends, as well as user authentication
methods, are used. The VPN connection over the Internet logically operates as a Wide Area Network (WAN) link
between the sites.
A VPN connects the components of a network using another network. To connect, the user tunnels through the
Internet or another public network using a protocol such as Microsoft Point-to-Point Tunneling Protocol (PPTP) or
Layer Two Tunneling Protocol (L2TP). This process provides the same security and features previously available
only in a private network. PPTP is available with the Microsoft Windows NT version 4.0 and Microsoft Windows
2000 (and later) operating systems; L2TP is available with Windows 2000 and later.
For the user, the intermediate routing infrastructure of the Internet is not visible and it appears as though the data
is being sent over a dedicated private link. As far as users are concerned, the VPN is a point-to-point connection
between the user computer and a corporate server.
After you have your remote client configured to connect using a VPN, and the client has Internet access and is
logged in to the corporate LAN, you can configure replication as though the remote client is connected directly on
the LAN. For security reasons, it is possible to have different network resources available to users connected over
VPN and to those connected directly on the LAN.
For more information about setting up a VPN, see the Microsoft Windows documentation.
See Also
Warehouse
Web synchronization for merge replication lets you replicate data by using the HTTPS protocol, and is useful for
the following scenarios:
Synchronizing data from mobile users over the Internet.
Synchronizing data between Microsoft SQL Server databases across a corporate firewall.
For example, a traveling sales representative can use Web synchronization. The company, Adventure
Works Cycles, has sales representatives that travel to various stores and suppliers throughout their
regions. On longer trips the representatives stay in hotels and need a convenient way to upload sales data
and download any product updates at the end of each day.
The Adventure Works IT department has configured each portable computer with SQL Server and has
enabled merge replication to use Web synchronization. The Merge Agent on each portable computer has
an Internet URL that points to the replication components that are installed on a computer that is running
Microsoft Internet Information Services (IIS). These components synchronize the Subscriber with the
Publisher. Each representative can now connect through any available Internet connection without using a
remote dial-up connection, and can upload and download the appropriate data. The Internet connection
uses Secure Sockets Layer (SSL); therefore, a virtual private network (VPN) is not required.
For information about how to configure the components that are required for Web synchronization, see
Configure Web Synchronization, Configure IIS for Web Synchronization, and Configure IIS 7 for Web
Synchronization.
NOTE
Web synchronization is designed for synchronizing data with portable computers, handheld devices, and other clients. Web
synchronization is not intended for high-volume server-to-server applications.
Overview of How Web Synchronization Works

When Web synchronization is used, updates at the Subscriber are packaged and sent as an XML message to the
computer that is running IIS by using the HTTPS protocol. The computer that is running IIS then sends the
commands to the Publisher in a binary format, typically by using TCP/IP. Updates at the Publisher are sent to the
computer that is running IIS and then packaged as an XML message for delivery to the Subscriber.
The following illustration shows some of the components that are involved in Web synchronization for merge
replication.
Web synchronization is an option only for pull subscriptions; therefore, a Merge Agent will always run on the
Subscriber. This Merge Agent can be the standard Merge Agent, the Merge Agent ActiveX control, or an
application that provides synchronization through Replication Management Objects (RMO). To specify the
location of the computer that is running IIS, use the InternetUrl parameter for the Merge Agent.
The SQL Server Replication Listener (Replisapi.dll) is configured on the computer that is running IIS and is
responsible for handling messages that are sent to the server from the Publisher and Subscribers. Each node in
the topology handles the XML data stream by using the Merge Replication Reconciler (Replrec.dll).
SQL Server 2005 or a later version is required for all computers that participate in Web synchronization.
Synchronization Process
The following steps occur during synchronization:
1. The Merge Agent is started at the Subscriber. The agent does the following:
a. Makes an SQL connection to the subscription database.
b. Extracts any changes from the database.
c. Makes an HTTPS request to the computer that is running IIS.
d. Uploads data changes as an XML message.
2. The SQL Server Replication Listener and Merge Replication Reconciler that are hosted on the computer
that is running IIS do the following:
a. Respond to the HTTPS request.
b. Make an SQL connection to the publication database.
c. Apply the upload changes to the publication database.
d. Extract the download changes for the Subscriber.
e. Send an HTTPS response back to the Merge Agent.
3. The Merge Agent at the Subscriber then accepts the HTTPS response and applies the download changes to
the subscription database.
See Also
Configure Web Synchronization
Topologies for Web Synchronization
Warehouse
The Web synchronization option for SQL Server Merge Replication enables data replication using the HTTPS
protocol over the Internet. To use Web synchronization, you first need to perform the following configuration
actions:
1. Create new domain accounts and map SQL Server logins.
2. Configure the computer that is running Microsoft Internet Information Services (IIS) to synchronize
subscriptions.
3. Configure a merge publication to allow Web synchronization.
4. Configure one or more subscriptions to use Web synchronization.
NOTE
If you plan to replicate large volumes of data or use large data types such as varchar(max), read the section "Replicating
Large Volumes of Data" in this topic.
To successfully set up Web synchronization, you must decide how you will configure security to meet your
particular requirements and policies. It is best to make these decisions and create the necessary accounts before
you attempt to configure IIS, the publication, and subscriptions.
In the procedures that follow, a simplified security configuration using local accounts is described, for brevity.
This simplified configuration is suitable for installations where both IIS and the SQL Server Publisher and
Distributor are running on the same computer, even though it is much more likely (and recommended) that you
will use a multiple-server topology for a production installation. You can substitute domain accounts for the local
accounts in the procedures.
Creating New Accounts and Mapping SQL Server Logins

The SQL Server Replication Listener (replisapi.dll) connects to the Publisher by impersonating the account
specified for the application pool that is associated with the replication web site.
The account used for the SQL Server Replication Listener must have permissions as described in Merge Agent
Security, under the section "Connect to the Publisher or Distributor." In summary, the account must:
Be a member of the Publication Access List (PAL).
Be mapped to a login associated with a user in the publication database.
Be mapped to a login associated with a user in the distribution database.
Have Read permissions on the snapshot share.
If this is the first time you are using SQL Server Replication, you will also need to create accounts and
logins for the replication agents. For more information, see the "Configuring the Publication" and
"Configuring the Subscription" sections in this topic.
Before you configure Web synchronization, we recommend that you read the "Security Best Practices for
Web Synchronization" section in this topic. For more information about Web synchronization security, see
Security Architecture for Web Synchronization.
Configuring the Computer That Is Running IIS

Web synchronization requires that you install and configure IIS. You will need the URL to the replication Web site
before you can configure a publication to use Web synchronization.
Web synchronization is supported on IIS beginning with version 5.0. The Configure Web Synchronization Wizard
is not supported on IIS version 7.0. Beginning with SQL Server 2012, to use the web sync component on IIS
server, we recommend users install SQL Server with replication. This can be the free SQL Server Express edition.
SSL is required for Web synchronization. You will need a security certificate issued by a certification authority. For
testing purposes only, you can use a self-issued security certificate.
To configure IIS for Web synchronization
SQL Server Management Studio: Configure IIS for Web Synchronization
SQL Server Management Studio: Configure IIS 7 for Web Synchronization
Creating a Web Garden

The SQL Server Replication Listener supports two concurrent synchronization operations per thread. Exceeding
this limit may cause the Replication Listener to stop responding. The number of threads allocated to replisapi.dll
is determined by the application pool Maximum Worker Processes property. By default, this property is set at 1.
You can support a greater number of concurrent synchronization operations per CPU by increasing the
Maximum Worker Process property value. Scaling out by increasing the number of worker processes per CPU is
known as creating a "Web garden."
Web gardening will allow more than two Subscribers to synchronize at the same time. It will also increase CPU
utilization by replisapi.dll, which can negatively impact overall server performance. It is important to balance
these considerations when you choose a value for Maximum Worker Processes.
To increase Maximum Worker Processes in IIS 7
1. In Internet Information Services (IIS) Manager, expand the local server node, and then click on the
Application Pool node.
2. Select the application pool associated with the Web synchronization site, and then click Advanced
Settings on the Actions pane.
3. On the Advanced Settings dialog, under the Process Model heading, click the row labeled Maximum
Worker Processes. Change the property value, and then click OK.
Configuring the Publication

To use Web synchronization, create a publication in the same way that you would for a standard merge topology.
For more information, see Publish Data and Database Objects.
After the publication is created, enable the option to allow for Web synchronization by using one of the following
methods: SQL Server Management Studio, Transact-SQL, or Replication Management Objects (RMO). To enable
Web synchronization, you will need to supply the Web server address for Subscriber connections.
If you are using a Publisher for the first time, you must also configure a Distributor and a snapshot share. The
Merge Agent at each Subscriber must have read permissions on the snapshot share. For more information, see
Configure Distribution and Secure the Snapshot Folder.
gen is a reserved word in websync xml files. Do not attempt to publish tables containing columns named gen.
Configuring the Subscription

After you enable a publication and configure IIS, create a pull subscription and specify that the pull subscription
should synchronize by using IIS. (Web synchronization is supported only for pull subscriptions.)
Upgrading from an Earlier Version of SQL Server

If you have an existing Web synchronization topology configured and you upgrade SQL Server, you must ensure
that the latest version of Replisapi.dll is copied to the virtual directory used by Web synchronization. By default,
the latest version of Replisapi.dll is located in C:\Program Files\Microsoft SQL Server\<nnn>\COM.
Replicating Large Volumes of Data

To help avoid potential memory problems on Subscriber computers Web synchronization uses a default
maximum size of 100 MB for the XML file used to transfer changes. The limit can be raised by setting the
following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\100\Replication
WebSyncMaxXmlSize DWORD 2000000
The range of acceptable values for this key is 100 MB to 4GB. The value is specified in KB. Setting this parameter
to a high value does not guarantee that you can synchronize that amount of data. The effective limit is
constrained by how much contiguous memory is available on the Subscriber computer. If you must have a value
larger than 100 MB, we recommend that you increase the value incrementally and test memory consumption
with a typical workload on the Subscriber.
The maximum size for the XML file is 4 GB, but replication synchronizes the changes from that file in batches. The
maximum batch size of data and metadata is 25 MB. You must ensure that the data in each batch does not exceed
approximately 20 MB, which allows for metadata and any other overhead. This limit has the following
implications:
You cannot replicate any column that causes the data and metadata to exceed 25 MB. This might be an
issue when you are replicating rows that contain large data types, such as varchar(max).
If you replicate large volumes of data, you might have to adjust the Merge Agent batch size.
Batch size for merge replication is measured in generations, which are collections of changes per article.
The number of generations in a batch is specified by using theDownloadGenerationsPerBatch and
UploadGenerationsPerBatch parameters of the Merge Agent. For more information, see Replication
Merge Agent.
For large volumes of data, specify a small number for each of the batching parameters. We recommend
that you start with a value of 10, and then tune based on application needs and performance. Typically,
these parameters are specified in an agent profile. For more information about profiles, see Replication
Agent Profiles.
Security Best Practices for Web Synchronization

There are many choices for security-related settings in Web synchronization. We recommend the following
approach:
The SQL Server Distributor and Publisher can be on the same computer (a typical setup for merge
replication). However, IIS should be installedon a separate computer.
Use Secure Sockets Layer (SSL) to encrypt the connection between the Subscriber and the computer
running IIS. This is required for Web synchronization.
Use Basic Authentication for connections from the Subscriber to IIS. Using Basic Authentication, IIS can
make connections to the Publisher/Distributor on behalf of the Subscriber without requiring delegation.
Delegation is required if you use Integrated Authentication.
NOTE
Basic Authentication is the method by which credentials are passed to IIS. Basic Authentication does not prevent
specifying Windows domain accounts for connections that are made to IIS.
Specify that the Snapshot Agent should run under a Windows domain account, and specify that the agent
should make connections as that account. (This is the default configuration.) Specify that each Merge
Agent should run under the domain account of the user that uses the Subscriber computer, and specify
that the agent should make connections as that account.
For more information about the permissions that are required by agents, see Replication Agent Security
Model.
Specify the same domain account as the one the Merge Agent uses when you specify an account and
password on the Web Server Information page of the New Subscription Wizard or when you specify
values for the @internet_url and @internet_login parameters of sp_addpullsubscription_agent. This
account must have read permissions for the snapshot share.
Each publication should use a separate virtual directory for IIS.
The account under which the SQL Server Replication Listener (Replisapi.dll) runs is also the account that
will connect to the Publisher and Distributor during synchronization. This account must be mapped to a
SQL Login account on the Publisher and Distributor. For more information, see the "Setting Permissions
for the SQL Server Replication Listener" section in the Configure IIS for Web Synchronization.
You can use FTP to deliver the snapshot from the Publisher to the computer that is running IIS. The
snapshot is always delivered from the computer that is running IIS to the Subscriber by using HTTPS. For
more information, see Transfer Snapshots Through FTP.
If servers in the replication topology are behind a firewall, you might need to open ports in the firewall to
enable Web synchronization.
The Subscriber computer connects to the computer that is running IIS over HTTPS using SSL, which
is typically configured to use port 443. SQL Server Compact Subscribers can also connect over
HTTP, which is typically configured to use port 80.
The computer that is running IIS typically connects to the Publisher or Distributor using port 1433
(default instance). When the Publisher or Distributor is a named instance on a server with another
default instance, port 1500 is typically used to connect to the named instance.
If the computer running IIS is separated from the Distributor by a firewall and an FTP share is used
for snapshot delivery, the ports used for FTP must be opened. For more information, see Transfer
Snapshots Through FTP.
IMPORTANT
Opening ports in your firewall can leave your server exposed to malicious attacks. Make sure that you understand firewall
systems before you open ports. For more information, see Security Considerations for a SQL Server Installation.
See Also
Topologies for Web Synchronization
Warehouse
You can choose from a variety of Microsoft SQL Server Web synchronization replication topologies. Common ways
to configure Web synchronization include:
Single server
Two servers
Multiple Microsoft Internet Information Services (IIS) systems and SQL Server republishing
For information about configuring Web synchronization, see Configure Web Synchronization.
Single Server
In the simplest topology, IIS, the SQL Server Publisher, and the SQL Server Distributor all reside on a single server.
Subscribers synchronize by connecting to IIS on the Publisher. The Publisher can be located behind a firewall.
NOTE
This configuration is recommended only for intranet scenarios. For other scenarios, it is recommended that the IIS server and
SQL Server Publisher/Distributor be on separate computers.
Two Servers
You can place IIS on one server and configure the SQL Server Publisher and Distributor on another server. The
server running IIS can be isolated from the Internet by a firewall. Subscribers synchronize by connecting to IIS.
Multiple IIS Systems and SQL Server Republishing

If you need to support very large numbers of Subscribers that synchronize at the same time, you can partition the
work across multiple computers running IIS.
If further load balancing is required on the computer running SQL Server, you can create a republishing hierarchy
on multiple computers. The top-level Publisher publishes data to Subscribers, which in turn republish the data, load
balancing requests from the Subscribers.
NOTE
Subscribers can only synchronize with a specific Publisher. For example, a Subscriber to republisher A cannot synchronize with
republisher B when A is not available.
See Also
Configure IIS for Web Synchronization
Warehouse
The procedures in this topic make up the second step in configuring Web synchronization for merge replication.
You perform this step after you enable a publication for Web synchronization. For an overview of the
configuration process, see Configure Web Synchronization. After you complete the procedures in this topic,
continue to the third step, configuring a subscription to use Web synchronization. This third step is described in
the following topics:
SQL Server Management Studio: How to: Configure a Subscription to Use Web Synchronization (SQL
Server Management Studio)
Replication Transact-SQL programming: How to: Configure a Subscription to Use Web Synchronization
(Replication Transact-SQL Programming)
RMO: How to: Configure a Subscription to Use Web Synchronization (RMO Programming)
Web synchronization uses a computer that is running Microsoft Internet Information Services (IIS) to
synchronize pull subscriptions to merge publications. IIS version 5.0, IIS version 6.0, and IIS 7.0 are
supported. The Configure Web Synchronization Wizard is not supported on IIS 7.0.
IMPORTANT
Make sure that your application uses only .NET Framework 2.0 or later versions, and that earlier versions of the .NET
Framework are not installed on the IIS server. Earlier versions of the .NET Framework can cause errors. These include the
following: "The format of a message during Web synchronization was invalid. Ensure that replication components are
properly configured at the Web server".
Cau t i on
Do not use both WebSync and alternate snapshot folder locations at the same time.
To use Web synchronization, you must configure IIS by completing the following steps. Each step is described in
detail in this topic.
1. Configure Secure Sockets Layer (SSL). SSL is required for communication between IIS and all Subscribers.
2. Install Microsoft SQL Server connectivity components on the computer that is running IIS by using the SQL
Server Installation Wizard. If you plan to use the Configure Web Synchronization Wizard that is mentioned
in step 3, you must also install SQL Server Management Studio on the computer that is running IIS.
3. Configure the computer that is running IIS for Web synchronization. You can configure the computer
manually or use the Configure Web Synchronization Wizard. We recommend that you use the wizard.
NOTE
If the computer that is running IIS is running on a 64-bit version of Windows, you must run following command to
make sure that the server is properly configured to run Internet Server API (ISAPI) applications. For more
information, see the IIS documentation.
cscript %SystemDrive%\inetpub\AdminScripts\adsutil.vbs set w3svc/AppPools/Enable32bitAppOnWin64 1
4. Set the appropriate permissions for the SQL Server Replication Listener.
5. Run Web synchronization in diagnostic mode to test the connection to the computer that is running IIS and
to make sure that the SSL certificate is properly installed.
Configuring Secure Sockets Layer

To configure SSL, specify a certificate for the computer that is running IIS to use. Web synchronization for merge
replication supports using server certificates but not client certificates. To configure IIS for deployment, you must
first obtain a certificate from a certification authority (CA). A certificate authority is an entity that is responsible for
establishing and vouching for the authenticity of public encryption keys that belong to users, computers, or other
certification authorities. For more information about certificates, see the IIS documentation. After you install the
certificate, you must associate the certificate with the Web site that is used by Web synchronization.
To specify a certificate for deployment
1. Log on to the computer that is running IIS as an administrator.
2. Start Internet Information Services (IIS) Manager:
a. Click Start, and then click Run.
b. In the Open box, type inetmgr, and then click OK.
3. Run the IIS Certificate Wizard:
a. In Internet Information Services (IIS) Manager, expand the local computer node, and then
expand the Web Sites folder.
b. Right-click Default Web Site, and then click Properties.
c. In the Default Web Site Properties dialog box, on the Directory Security tab, click Server
Certificate.
d. Complete the Web Server Certificate Wizard.
4. Click OK.
If you cannot obtain a server certificate from a CA, you can specify a certificate for testing. To configure IIS
6.0 for testing, install a certificate by using the SelfSSL utility. This utility is available in the IIS 6.0 Resource
Kit. You can download the tools from the Microsoft Download Center. For IIS 5.0, go to Microsoft Help and
Support.
NOTE
A certificate must be associated with a Web site before that Web site can use SSL. SelfSSL automatically associates the
certificate with the default Web site. If you already have a certificate or later install a certificate from a CA, you must explicitly
associate that certificate with the Web site that is used by Web synchronization. Make sure there is only one certificate
associated with the Web site that is used to synchronize subscriptions. If there are multiple certificates, the Subscriber will
use the first available Web site.
To specify a certificate for testing in IIS 6.0

1. Log on to the computer that is running IIS as an administrator.
2. Download and install SelfSSL. By default, the application is installed to <drive>:\Program Files\IIS
Resources\SelfSSL. Application and documentation shortcuts are copied to <drive>:\Documents and
Settings\All Users\Start Menu\Programs\IIS Resources\SelfSSL.
3. Run SelfSSL:
To run SelfSSL with default values for all parameters, locate the installation directory for the
application, and then double-click SelfSSL.exe.
NOTE
By default, the certificate that is installed by SelfSSL is valid for seven days.
To specify values for one or more parameters: click Start, and then click Run. In the Open box, enter
cmd, and then click OK. Locate the SelfSSL installation directory, type SelfSSL , and then specify
values for one or more parameters. For a list of parameters, type SelfSSL -? .
Installing Connectivity Components and SQL Server Management

Studio
To install SQL Server connectivity components and SQL Server Management Studio
1. Log on as an administrator to the computer that is running IIS.
2. From the SQL Server 2012 installation disk, start the SQL Server Installation Wizard. For more information
about using this wizard, see Install SQL Server 2016 from the Installation Wizard (Setup).
3. On the Feature Selection page, select Client Tools Connectivity.
4. If you plan to use the Configure Web Synchronization Wizard, select Management Tools - Basic.
5. Complete the wizard, and then restart the computer.
NOTE
You can install additional components, but only the connectivity components are required for Web synchronization.
Configuring the Computer That Is Running IIS by Using the Configure

Web Synchronization Wizard
Configure the IIS server by using the Configure Web Synchronization Wizard or manually. We recommend using
the wizard, but we also provide steps for manual configuration in the next section. The Web Synchronization
Wizard that is available with SQL Server 2012 can be used only for publications that were created on a Publisher
that is running SQL Server 2012, or a Publisher that was upgraded to SQL Server 2012. The wizard cannot be used
for publications on SQL Server 2005. The wizard can be used with subscriptions on SQL Server 2005 and later
versions, and SQL Server Compact 3.5 3.0 and later versions.
The configuration has the following characteristics:
Uses the default Web site in IIS. However, you can use another Web site. For more information about how
to create Web sites, see the IIS documentation.
NOTE
The Web site that you specify provides access to the components that are used by Web synchronization. The Web
site does not provide access to other data or Web pages unless you configure the site to do so.
Creates a virtual directory and its associated alias. The alias is used when accessing the Web
synchronization components. For example, if the IIS address is https://server.domain.com and you specify
an alias of 'websync1', the address to access the replisapi.dll component is
https://server.domain.com/websync1/replisapi.dll .
Uses Basic Authentication. We recommend using Basic Authentication because Basic Authentication enables
you to run IIS and the SQL Server Publisher/Distributor on separate computers (the recommended
configuration) without requiring Kerberos delegation. Using SSL with Basic Authentication makes sure that
logins, passwords, and all data are encrypted in transit. (SSL is required, regardless of the type of
authentication that is used.) For more information about best practices for Web synchronization, see the
section "Security Best Practices for Web Synchronization" in Configure Web Synchronization.
To configure the computer that is running IIS by using the Configure Web Synchronization Wizard
1. On the computer that is running IIS, start SQL Server Management Studio.
2. Connect to the Publisher, and then expand the server node.
3. Expand the Local Publications folder, right-click the publication, and then click Configure Web
Synchronization.
4. In the Configure Web Synchronization Wizard, on the Subscriber Type page, select SQL Server.
5. On the Web Server page:
a. Select the instance of IIS that will synchronize subscriptions.
b. Select Create a new virtual directory.
c. In the lower pane of the page, expand the instance of IIS, expand Web Sites, and then click Default
Web Site.
6. On the Virtual Directory Information page:
a. In the Alias box, enter an alias for the virtual directory.
b. In the Path box, enter a path of the virtual directory. For example, if you entered websync1 in the
Alias box, enter C:\Inetpub\wwwroot\websync1 in the Path box. Click Next.
c. On both dialog boxes, click Yes. This specifies that you want to create a new folder and that you want
to copy the SQL Server Internet Server API (ISAPI) DLL. .
7. On the Authenticated Access page:
a. Make sure that Integrated Windows authentication and Digest authentication for Windows
domain servers are cleared.
b. Select Basic Authentication.
c. In the Default Domain and Realm boxes, enter the domain of the computer that is running IIS.
8. On the Directory Access page:
a. Click Add, and then in the Select Users or Groups dialog box, add the accounts under which
Subscribers will make connections to IIS. These are the accounts that you will specify on the Web Server
Information page of the New Subscription Wizard or as the value for the
sp_addmergepullsubscription_agent@internet_login parameter.
9. On the Snapshot Share Access page, enter the snapshot share. The appropriate permissions are set on
this share so that Subscribers can access the snapshot files. For more information about permissions for the
share, see Secure the Snapshot Folder.
10. On the Completing the Wizard page, click Finish.
If a failure occurs, such as a network error while trying to configure a remote computer that is running IIS,
all completed actions are rolled back and all remaining actions are canceled. If a completed action cannot be
rolled back, the status in the final page of the wizard displays Success and the completed actions remain
committed.
11. If the computer that is running IIS is running on a 64-bit version of Windows, replisapi.dll must be copied to
the appropriate directory:
a. Click Start, and then click Run. In the Open box, enter iisreset, and then click OK.
b. After IIS stops and restarts, copy replisapi.dll from <drive>:\Program Files\Microsoft SQL
Server\nnn\COM\replisapi to the directory that is specified in step 6b.
c. Click Start, and then click Run. In the Open box, enter cmd, and then click OK.
d. In the directory that you specified in step 6b, execute the following command:
regsvr32 replisapi.dll
Manually Configuring the Computer That Is Running IIS

To configure the computer that is running IIS manually, you must install and configure the SQL Server Replication
Listener, and then configure authorization for Subscribers that will connect to IIS.
To install and configure the SQL Server Replication Listener
1. Create a file directory on the computer that is running IIS to contain replisapi.dll. You can create the
directory wherever you want, but we recommend that you create the directory under the <drive>:\Inetpub
directory. For example, create the directory <drive>:\Inetpub\SQLReplication\.
IMPORTANT
We strongly recommend that you create this directory on an NTFS file system partition instead of a FAT file system.
When you use the NTFS file system, you can use NTFS file system permissions to control precisely the users that can
access SQL Server replication.
2. Copy replisapi.dll from the directory <drive>:\Program Files\Microsoft SQL Server\nnn\com\ to the file
directory that you created in step 1.
3. Register replisapi.dll:
a. Click Start, and then click Run. In the Open box, enter cmd, and then click OK.
b. In the directory that you created in step 1, execute the following command:
4. Create a new Web site for replication, or use an existing site. The Web site will be accessed by replication
components during synchronization. For more information about how to create Web sites, see the IIS
documentation.
5. Create a virtual directory in IIS. The virtual directory should be created under the Web site that was created
in step 4, and should be mapped to the directory that was created in step 1. For more information about
how to create virtual directories, see the IIS documentation. We recommend that you be as restrictive as
possible when you assign permissions to this directory. You must select Read and Execute permissions,
but you can clear Run scripts, Write, and Browse permissions.
6. Configure IIS to enable replisapi.dll to execute. The permissions that are assigned in step 4 are sufficient for
earlier versions of IIS; however, IIS version 6.0 requires Internet Server API (ISAPI) extensions to be enabled.
For more information, see "Configuring ISAPI Extensions" and "Enabling and Disabling Dynamic Content" in
the IIS 6.0 documentation.
To configure IIS authentication
When Subscribers connect to IIS, IIS must authenticate the Subscribers before they can access resources
and processes. IIS offers three types of authentication: Anonymous, Basic, and Integrated. Authentication
can be applied to the whole Web site or to the virtual directory that you created.
We recommend that you use Basic Authentication with SSL. SSL is required, regardless of the type of
authentication that is used. For more information about how to configure authentication, see the IIS
documentation.
Setting Permissions for the SQL Server Replication Listener

When a Subscriber connects to the computer that is running IIS, the Subscriber is authenticated by using the type
of authentication that was specified when you configured IIS. After IIS authenticates the Subscriber, IIS checks
whether the Subscriber is authorized to invoke SQL Server replication. You control the users that can invoke SQL
Server replication by setting permissions for replisapi.dll. Properly configuring permissions is necessary to prevent
unauthorized access to SQL Server replication.
To configure the minimum permissions for the account under which the SQL Server Replication Listener runs,
complete the following procedure. The steps in the procedure apply to Microsoft Windows Server 2003 running
IIS 6.0.
In addition to performing the following steps, make sure that the required logins are in the publication access list
(PAL). For more information about the PAL, see Secure the Publisher.
To configure the account and permissions
1. Create a local account on the computer that is running IIS:
a. Right-click My Computer, and then click Manage.
b. In Computer Management, expand Local Users and Groups.
c. Right-click Users, and then click New User.
d. Enter a user name and a strong password.
e. Click Create, and then click Close.
2. Add the account to the IIS_WPG group:
a. In Computer Management, expand Local Users and Groups, and then click Groups.
b. Right-click IIS_WPG, and then click Add to Group.
c. In the IIS_WPG Properties dialog box, click Add.
d. In the Select Users, Computers, or Groups dialog box, add the account created in step 1.
e. Make sure that the name in the From this location field is the name of the local computer instead
of a domain. If the name is not a local computer, click Locations. In the Locations dialog box, elect
the local computer, and then click OK.
f. In the Select Users dialog box and the IIS_WPG Properties dialog box, click OK.
3. Grant the minimum permissions on the folder that contains replisapi.dll to the account :
a. Locate the folder that you created for replisapi.dll, right-click the folder, and then click Sharing and
Security.
b. On the Security tab, click Add.
c. In the Select Users, Computers, or Groups dialog box, add the account that you created in step 1.
d. Make sure that the name in the From this location field is the name of the local computer instead
of a domain. If the name is not a local computer, click Locations. In the Locations dialog box, select
the local computer, and then click OK.
e. Make sure that the account is granted only Read, Read & Execute, and List Folder Contents
permissions.
f. Select any users or groups that do not require access to the directory, and then click Remove.
g. Click OK.
4. Create an application pool in Internet Information Services (IIS) Manager:
a. Click Start, and then click Run.
b. In the Open box, type inetmgr, and then click OK.
c. In Internet Information Services (IIS) Manager, expand the local computer node.
d. Right-click Application Pools, point to New and then click Application Pool.
e. Enter a name for the pool in the Application pool ID field, and then click OK.
5. Associate the account with the application pool:
expand Application Pools.
b. Right-click the application pool that you created, and then click Properties.
c. In the <ApplicationPoolName> Properties dialog box, on the Identity tab, click Configurable.
d. In the User name and password fields, enter the account and password that were created in step 1.
e. Click OK.
6. Associate the application pool with the virtual directory that is used for Web synchronization:
expand Web Sites.
b. Expand the Web site that you are using for Web synchronization, right-click the virtual directory that
you created for Web synchronization, and then click Properties.
c. On the Virtual Directory tab of the <VirtualDirectoryName> Properties dialog box, from the
Application pool drop-down list, select the application pool that was created in step 5.
d. Click OK.
Testing the Connection to replisapi.dll

Run Web synchronization in diagnostic mode to test the connection to the computer that is running IIS and to
make sure that the Secure Sockets Layer (SSL) certificate is properly installed. To run Web synchronization in
diagnostic mode, you must be an administrator on the computer running IIS.
To test the connection to replisapi.dll
1. Make sure that local area network (LAN) settings at the Subscriber are correct:
a. In Microsoft Internet Explorer, on the Tools menu, click Internet Options.
b. On the Connections tab, click LAN Settings.
c. If a proxy server is not used on the LAN, clear Automatically Detect Settings and Use a proxy
server for your LAN.
d. If a proxy server is used, select Use a proxy server for your LAN and Bypass proxy server for
local addresses.
e. Click OK.
2. At the Subscriber, in Internet Explorer, connect to the server in diagnostic mode by appending ?diag to the
address for the replisapi.dll. For example: https://server.domain.com/directory/replisapi.dll?diag .
3. If the certificate that you specified for IIS is not recognized by the Windows operating system, the Security
Alert dialog box appears. This alert might occur because the certificate is a test certificate or the certificate
was issued by a certification authority (CA) that Windows does not recognize.
NOTE
If this dialog box does not appear, make sure that the certificate for the server that you are accessing has been
added to the certificate store at the Subscriber as a trusted certificate. For more information about exporting
certificates, see the IIS documentation.
a. In the Security Alert dialog box, click View Certificate.

b. In the Certificate dialog box, on the General tab, click Install Certificate.
c. Complete the Certificate Import Wizard, accepting the defaults.
d. In the Security Warning dialog box, click Yes.
e. In the Certificate Import Wizard confirmation dialog box, click OK.
f. Close the Certificate dialog box.
g. In the Security Alert dialog box, click Yes.
NOTE
Certificates are installed for users. This process must be performed for each user that will synchronize with IIS.
4. In the Connect to <ServerName> dialog box, specify the login and password that the Merge Agent will
use to connect to IIS. These credentials will also be specified in the New Subscription Wizard.
5. In the Internet Explorer window called SQL Websync diagnostic information, verify that the value in each
Status column on the page is SUCCESS.
6. Make sure that the certificate is installed correctly on the Subscriber:
a. Close and then reopen Internet Explorer.
b. Connect to the server in diagnostic mode. If the certificate is installed properly, the Security Alert
dialog box will not appear. If the dialog box appears, the Merge Agent will fail when it tries to connect
to the computer that is running IIS. You must make sure that the certificate for the server that you
are accessing has been added to the certificate store at the Subscriber as a trusted certificate. For
more information about exporting certificates, see the IIS documentation.
See Also
Configure IIS 7 for Web Synchronization
Warehouse
The procedures in this topic will guide you through the process of manually configuring Microsoft Internet
Information Services (IIS) version 7 and higher for use with Web synchronization for merge replication.
Configuring IIS 7 or higher is the first of three steps needed to enable Web synchronization.
For an overview of the entire configuration process, see Configure Web Synchronization.
IMPORTANT
Make sure that your application uses only .NET Framework 2.0 or later versions, and that earlier versions of the .NET
Framework are not installed on the IIS server. Earlier versions of the .NET Framework can cause errors, such as: "The format
of a message during Web synchronization was invalid. Ensure that replication components are properly configured at the
Web server."
To use Web synchronization, you must configure IIS by completing the following steps. Each step is described in
detail in this topic.
1. Install and configure the Microsoft SQL Server Replication Listener on the computer that is running IIS.
2. Configure Secure Sockets Layer (SSL). SSL is required for communication between IIS and all subscribers.
3. Configure IIS authentication.
4. Configure an account and set permissions for the SQL Server Replication Listener.
Installing the SQL Server Replication Listener

Web synchronization is supported on IIS, beginning with version 5.0. The Configure Web Synchronization Wizard
of IIS version 5 and 6, is not available with IIS version 7.0 and higher. Beginning with SQL Server 2012, to use
the web sync component on IIS server, you should install SQL Server with replication. This can be the
free SQL Server Express edition.
To install and configure the SQL Server Replication Listener
1. Install SQL Server replication on the IIS computer.
2. Create a new file directory for replisapi.dll on the computer that is running IIS. You can create the directory
wherever you want, but we recommend that you create the directory under the <drive>:\Inetpub directory.
For example, create the directory <drive>:\Inetpub\SQLReplication\.
3. Copy replisapi.dll from the directory <drive>:\Program Files\Microsoft SQL Server\nnn\com\ to the file
directory that you created in step 1.
4. Register replisapi.dll:
a. Click Start, and then click Run. In the Open box, enter cmd, and then click OK.
b. In the directory created in step 1, execute the following command:
5. Create a new Web site for replication or use an existing site. This Web site will be accessed by replication
components during synchronization. Procedures in this topic will assume the Default Web Site. For more
information about how to create Web sites, see the IIS documentation
6. Create a virtual directory in IIS. The virtual directory should be created under the Web site that you created
in step 4 and map it to the directory created in step 1. Be as restrictive as possible when you assign
permissions to this directory. You must select at least Read and Execute permissions.
a. In Internet Information Services (IIS) Manager, in the Connections pane, right-click Default
Web Site, and then select Add Virtual Directory.
b. For Alias, enter SQLReplication.
c. For Physical Path, enter <drive>:\Inetpub\SQLReplication\, and then click OK.
7. Configure IIS to enable replisapi.dll to execute.
a. In Internet Information Services (IIS) Manager, click Default Web Site.
b. In the center pane, click Handler Mappings.
c. In the Actions pane, click Add Module Mapping.
d. For Request Path, enter replisapi.dll.
e. From the Module drop-down list, select IsapiModule.
f. For Executable, enter <drive>:\Inetpub\SQLReplication\replisapi.dll.
g. For Name, enter Replisapi.
h. Click the Request Restrictions button, click the Access tab, and then click Execute.
i. Click OK to close the Request Restrictions dialog box, and then click OK again to close the Add
Module Mapping dialog box. When you are prompted to allow the ISAPI extension, click Yes to add
the extension.
j. Verify that Replisapi.dll is listed under the Enabled handler mappings. If it is in the Disabled list,
right-click the Replisapi entry and then click Edit Feature Permissions. Check the Execute box, and
then click OK.
Configuring IIS Authentication

When subscriber computers connect to IIS, IIS must authenticate the subscribers before they can access resources
and processes. Authentication can be applied to the whole Web site or to the virtual directory that you created.
authentication that is used.
authentication that is used.
To Configure IIS Authentication
1. In Internet Information Services (IIS) Manager, click Default Web Site.
2. In the middle pane, double-click Authentication.
3. Right-click Anonymous Authentication, and then choose Disable.
4. Right-click Basic Authentication, and then choose Enable.
Configuring Secure Sockets Layer
To configure SSL, specify a certificate to be used by the computer running IIS. Web synchronization for merge
replication supports using server certificates, but not client certificates. To configure IIS for deployment, you must
first obtain a certificate from a certification authority (CA). For more information about certificates, see the IIS
documentation.
After you install the certificate, you must associate the certificate with the Web site that is used by Web
synchronization. For development and testing, you can specify a self-signed certificate. IIS 7 can create a certificate
for you and register it on your computer.
The difference between deploying for production and the procedures given here is that in production and pre-
production testing, you would use a certificate issued by a CA instead of a self-signed certificate.
IMPORTANT
A self-signed certificate is not recommended for a production installation. Self-signed certificates are not secure. Use self-
signed certificates for development and testing only.
To configure SSL, you will perform the following steps:

1. Configure the Web site to require SSL and ignore client certificates.
2. Obtain a certificate from a CA or create a self-signed certificate.
3. Bind the certificate to the replication Web site.
To require SSL security for a Web site
1. In Internet Information Services (IIS) Manager, expand the local server node, and then click the Default
Web Site (or your Web synchronization site if it is different from the default Web site).
2. In the middle pane, double-click SSL Settings.
3. Check the Require SSL option. Under Client certificates, verify that the Ignore button is selected.
To create a self-signed certificate for testing
1. In Internet Information Services (IIS) Manager, click the local server node, and then in the center pane,
double-click on Server Certificates.
2. In the Actions pane, click Create Self-Signed Certificate.
3. In the Create Self-Signed Certificate dialog box, enter a name for the certificate, and then click OK.
To b i n d a c e rt i f i c a t e t o a W e b s i t e
1. In the Connections pane, click the Default Web Site (or your Web synchronization site, if it is different
from the default Web site).
2. In the Actions pane, click Bindings, and then click Add. The Add Site Binding dialog box will appear.
3. From the Type drop-down list, select https. Leave the default settings for IP address and Port.
4. From the SSL certificate drop-down list, select the certificate created in "To create a self-signed certificate
for testing," click OK, and then click Close.
To t e s t t h e c e rt i f i c a t e
1. In Internet Information Services (IIS) Manager, click Default Web Site.

2. From the Actions pane, click Browse *:443(https).
3. Internet Explorer will open and display a message that "There is a problem with this website's security
certificate." This warning tells you that the associated certificate was not issued by a recognized CA and
might not be trustworthy. This is an expected warning, so click Continue to this website (not
recommended).
4. If you are prompted to Connect to localhost, enter a user name and password to proceed. You should see
the default page for the Web site.
Setting Permissions for the SQL Server Replication Listener

When a subscriber computer connects to the computer running IIS, the subscriber is authenticated by using the
type of authentication specified when you configured IIS. After IIS authenticates the subscriber, IIS checks whether
the subscriber is authorized to invoke SQL Server replication. You control the users that can invoke SQL Server
replication by setting permissions for replisapi.dll. Properly configuring permissions is necessary to prevent
unauthorized access to SQL Server replication.
To configure the minimum permissions for the account under which the SQL Server Replication Listener runs,
complete the following procedure. The steps in the following procedure apply to Microsoft Windows Server 2008
running IIS 7.0.
In addition to performing the following steps, make sure that the required logins are in the publication access list
(PAL). For more information about the PAL, see Secure the Publisher.
Important The account created in this section is the account that will connect to the Publisher and Distributor
during synchronization. This account must be added as a SQL Login account on the distribution and publication
server.
The account used for the SQL Server Replication Listener must have permissions as described in the Merge Agent
Security topic, in the "Connect to the Publisher or Distributor" section.
In summary, the account must:
Be a member of the Publication Access List (PAL).
Be mapped to a login associated with a user in the publication database.
Be mapped to a login associated with a user in the distribution database.
Have Read permissions on the snapshot share.
To configure the account and permissions
1. Create a local account on the computer running IIS:
a. Open Server Manager. From the Start menu, right-click Computer, and then click Manage.
b. In Server Manager, expand Configuration, and then expand Local Users and Groups.
c. Right-click Users, and then click New User.
d. Enter a user name and a strong password. Clear User must change password at next logon.
e. Click Create, and then click Close.
2. Add the account to the IIS_IUSRS group:
a. In Server Manager, expand Configuration, expand Local Users and Groups, and then click
Groups.
b. Right-click IIS_IUSRS, and then click Add to Group.
c. In the IIS_IUSRS Properties dialog box, click Add.
d. In the Select Users, Computers, or Groups dialog box, add the account created in step 1.
e. Verify that From this location displays the name of the local computer (not a domain). If this field
does not display the local computer name, click Locations. In the Locations dialog box, select the
local computer, and then click OK.
f. In the Select Users dialog box and the IIS_IUSRS Properties dialog box, clickOK.
3. Grant minimum account permissions on the folder that contains replisapi.dll:
a. In Windows Explorer, right-click the folder that you created for replisapi.dll, and then click
Properties.
b. On the Security tab, click Edit.
c. In the Permissions for <foldername> dialog box, click Add to add the account that you created in
step 1.
d. Verify that From this location displays the name of the local computer (not a domain). If this field
does not display the local computer name, click Locations. In the Locations dialog box, select the
local computer, and then click OK.
e. Verify that the account is granted only Read, Read & Execute, and List Folder Contents
permissions.
f. Select any users or groups that do not require access to the directory, click Remove, and then click
OK.
4. Create an application pool in Internet Information Services (IIS) Manager:
a. In Internet Information Services (IIS) Manager, in the Connections pane, expand the local server
node.
b. Right-click Application Pools, and then click Add Application Pool.
c. Enter a name for the application pool, leave the default values for the remaining fields, and then click
OK.
NOTE
If you anticipate having more than two concurrent synchronization clients, you might want to create a web garden.
For more information, see "Creating a Web Garden" in Configure Web Synchronization.
5. Associate the account with the application pool:

a. In Internet Information Services (IIS) Manager, expand the local server node, and then click on
Application Pools.
b. Right-click the application pool that you created, and then click Set Application Pool Defaults.
c. In the Application Pool Defaults dialog box, scroll down to the Process Model section, and then
click the Identity field.
d. Click the ellipsis button on the right side of the Identity row.
e. Click the Custom Account radio button, and then click Set.
f. In the User name and Password fields, enter the account and password that were created in step 1,
and then click OK.
g. Click OK to close the Application Pool Identity dialog box, and then click OK again to close the
Application Pool Defaultsdialog box.
6. Associate the application pool with the replication Web site:
a. In Internet Information Services (IIS) Manager, expand the local server node, and then click on
the Default Web Site (or your Web synchronization site if it is different from the default Web site).
b. In the Actions pane, under Manage Web Site, click Advanced Settings.
c. In the Advanced Settings dialog box, click on the ellipsis button to the right of Application Pool.
d. From the Application pool drop-down list, select the application pool you created in step 4, and
then click OK.
e. Click OK again to close Advanced Settings.
Testing the Connection to replisapi.dll

Run Web synchronization in diagnostic mode to test the connection to the computer running IIS and to make sure
that the Secure Sockets Layer (SSL) certificate is properly installed. To run Web synchronization in diagnostic
mode, you must be an administrator on the computer running IIS.
To test the connection to replisapi.dll
1. Make sure that local area network (LAN) settings at the Subscriber are correct:
a. In Microsoft Internet Explorer, on the Tools menu, click Internet Options.
b. On the Connections tab, click LAN Settings.
c. If a proxy server is not used on the LAN, clear Automatically Detect Settings and Use a proxy
server for your LAN.
d. If a proxy server is used, click Use a proxy server for your LAN and Bypass proxy server for local
addresses, and then click OK.
2. At the Subscriber, in Internet Explorer, connect to the server in diagnostic mode by appending ?diag to the
address for the replisapi.dll. For example: https://server.domain.com/directory/replisapi.dll?diag .
NOTE
In the example above, server.domain.com should be replaced with the exact Issued To name listed under the
Server Certificates section in IIS Manager.
3. If the certificate that you specified for IIS is not recognized by the Windows operating system, the Security
Alert dialog box appears. This alert might occur because the certificate is a test certificate or the certificate
was issued by a certification authority (CA) that Windows does not recognize.
NOTE
If this dialog box does not appear, make sure that the certificate for the server that you are accessing has been
added to the certificate store at the Subscriber as a trusted certificate. For more information about exporting
certificates, see the IIS documentation.
a. In the Security Alert dialog box, click View Certificate.

b. In the Certificate dialog box, on the General tab, click Install Certificate.
c. Complete the Certificate Import Wizard, accepting the defaults.
d. In the Security Warning dialog box, click Yes.
e. In the Certificate Import Wizard confirmation dialog box, click OK.
f. Close the Certificate dialog box.
g. In the Security Alert dialog box, click Yes.
NOTE
Certificates are installed for users. This process must be performed for each user that will synchronize with IIS.
4. In the Connect to <ServerName> dialog box, specify the login and password that the Merge Agent will
use to connect to IIS. These credentials will also be specified in the New Subscription Wizard.
5. In the Internet Explorer window called SQL Websync diagnostic information, verify that the value in each
Status column on the page is SUCCESS.
6. Make sure that the certificate is installed correctly on the Subscriber:
a. Close and then reopen Internet Explorer.
b. Connect to the server in diagnostic mode. If the certificate is installed properly, the Security Alert
dialog box will not appear. If the dialog box appears, the Merge Agent will fail when it tries to connect
to the computer that is running IIS. You must make sure that the certificate for the server that you are
accessing has been added to the certificate store at the Subscriber as a trusted certificate. For more
information about exporting certificates, see the IIS documentation.
See Also
Data Warehouse
The Distributor is a server that contains the distribution database, which stores metadata and history data for all
types of replication and transactions for transactional replication. To set up replication, you must configure a
Distributor. Each Publisher can be assigned to only a single Distributor instance, but multiple publishers can
share a Distributor. The Distributor uses these additional resources on the server where it is located:
Additional disk space if the snapshot files for the publication are stored on the Distributor (which they
typically are).
Additional disk space to store the distribution database.
Additional processor usage by replication agents for push subscriptions running on the Distributor.
The server you select as the Distributor should have adequate disk space and processor power to
support replication and any other activities on that server. When you configure the Distributor, you
specify the following:
A snapshot folder, which is used, by default, for all Publishers that use this Distributor. Ensure that this
folder is already shared and has the appropriate permissions set. For more information, see Secure the
Snapshot Folder.
A name and file locations for the distribution database. The distribution database cannot be renamed
after it is created. To use a different name for the database, you must disable distribution and reconfigure
it.
Any Publishers authorized to use the Distributor. If you specify Publishers other than the instance on
which the Distributor runs, you must also specify a password for the connections the Publishers make to
the remote Distributor.
For transactional replication, after you configure distribution, we recommend that you:
Size the distribution database appropriately. Test replication with a typical load for your system to
determine how much space is required to store commands. Ensure the database is large enough to store
commands without having to auto-grow frequently. For more information about changing the size of a
database, see ALTER DATABASE (Transact-SQL).
Set the sync with backup option on the distribution database. For more information, see Strategies for
Backing Up and Restoring Snapshot and Transactional Replication and Enable Coordinated Backups for
Transactional Replication (Replication Transact-SQL Programming).
Local and Remote Distributors

By default, the Distributor is the same server as the Publisher (a local Distributor), but it can also be a separate
server from the Publisher (a remote Distributor). Typically, you would choose to use a remote Distributor if you
want to:
Offload processing to another computer if you want minimal impact from replication on the Publisher
(for example, if the Publisher is an OLTP server).
Configure a centralized Distributor for multiple Publishers.
Remote Distributors are more common in transactional replication than they are in merge replication for
two reasons:
The Distributor plays a larger role in transactional replication because all replicated transactions are
written to and read from the distribution database.
Merge replication topologies typically use pull subscriptions, so agents run at each Subscriber, rather
than all running at the Distributor. For more information, see Subscribe to Publications. In most cases,
you should use a local Distributor for merge replication.
To configure publishing and distribution, see Configure Publishing and Distribution.
To modify Publisher and Distributor properties, see View and Modify Distributor and Publisher
Properties.
See Also
Secure the Distributor
Warehouse
This topic describes how to configure publishing and distribution in SQL Server 2017 by using SQL Server
Management Studio, Transact-SQL, or Replication Management Objects (RMO).
Before You Begin

Security
For more information, see Secure Deployment (Replication).
Using SQL Server Management Studio

Configure distribution using the New Publication Wizard or the Configure Distribution Wizard. After the
Distributor is configured, view and modify properties in the Distributor Properties - <Distributor> dialog box.
Use the Configure Distribution Wizard if you want to configure a Distributor so that members of the db_owner
fixed database roles can create publications, or because you want to configure a remote Distributor that is not a
Publisher.
To configure distribution
1. In Microsoft SQL Server Management Studio, connect to the server that will be the Distributor (in many
cases, the Publisher and Distributor are the same server), and then expand the server node.
2. Right-click the Replication folder, and then click Configure Distribution.
3. Follow the Configure Distribution Wizard to:
Select a Distributor. To use a local Distributor, select '<ServerName>' will act as its own
Distributor; SQL Server will create a distribution database and log. To use a remote
Distributor, select Use the following server as the Distributor, and then select a server. The
server must already be configured as a Distributor, and the Publisher must be enabled to use the
Distributor. For more information, see Enable a Remote Publisher at a Distributor (SQL Server
Management Studio).
If you select a remote Distributor, you must enter a password on the Administrative Password
page for connections made from the Publisher to the Distributor. This password must match the
password specified when the Publisher was enabled at the remote Distributor.
Specify a root snapshot folder (for a local Distributor). The snapshot folder is simply a directory that
you have designated as a share; agents that read from and write to this folder must have sufficient
permissions to access it. Each Publisher that uses this Distributor creates a folder under the root
folder, and each publication creates folders under the Publisher folder in which to store snapshot
files. For more information on securing the folder appropriately, see Secure the Snapshot Folder.
Specify the distribution database (for a local Distributor). The distribution database stores metadata
and history data for all types of replication and transactions for transactional replication.
Optionally enable other Publishers to use the Distributor. If other Publishers are enabled to use the
Distributor, you must enter a password on the Distributor Password page for connections made
from these Publishers to the Distributor.
Optionally script configuration settings. For more information, see Scripting Replication.
Using Transact-SQL
Replication publishing and distribution can be configured programmatically using replication stored procedures.
To configure publishing using a local distributor
1. Execute sp_get_distributor (Transact-SQL) to determine if the server is already configured as a Distributor.
If the value of installed in the result set is 0, execute sp_adddistributor (Transact-SQL) at the
Distributor on the master database.
If the value of distribution db installed in the result set is 0, execute sp_adddistributiondb
(Transact-SQL) at the Distributor on the master database. Specify the name of the distribution
database for @database. Optionally, you can specify the maximum transactional retention period
for @max_distretention and the history retention period for @history_retention. If a new
database is being created, specify the desired database property parameters.
2. At the Distributor, which is also the Publisher, execute sp_adddistpublisher (Transact-SQL), specifying the
UNC share that will be used as default snapshot folder for @working_directory.
3. At the Publisher, execute sp_replicationdboption (Transact-SQL). Specify the database being published for
@dbname, the type of replication for @optname, and a value of true for @value.
To configure publishing using a remote distributor
1. Execute sp_get_distributor (Transact-SQL) to determine if the server is already configured as a Distributor.
If the value of installed in the result set is 0, execute sp_adddistributor (Transact-SQL) at the
Distributor on the master database. Specify a strong password for @password. This password for
the distributor_admin account will be used by the Publisher when connecting to the Distributor.
If the value of distribution db installed in the result set is 0, execute sp_adddistributiondb
(Transact-SQL) at the Distributor on the master database. Specify the name of the distribution
database for @database. Optionally, you can specify the maximum transactional retention period
for @max_distretention and the history retention period for @history_retention. If a new
database is being created, specify the desired database property parameters.
2. At the Distributor, execute sp_adddistpublisher (Transact-SQL), specifying the UNC share that will be used
as default snapshot folder for @working_directory. If the Distributor will use SQL Server Authentication
when connecting to the Publisher, you must also specify a value of 0 for @security_mode and the
Microsoft SQL Server login information for @login and @password.
3. At the Publisher on the master database, execute sp_adddistributor (Transact-SQL). Specify the strong
password used in step 1 for @password. This password will be used by the Publisher when connecting to
the Distributor.
4. At the Publisher, execute sp_replicationdboption (Transact-SQL). Specify the database being published for
@dbname, the type of replication for @optname, and a value of true for @value.
Example (Transact-SQL )
The following example demonstrates how to configure publishing and distribution programmatically. In this
example, the name of the server that is being configured as a publisher and a local distributor is supplied using
scripting variables. Replication publishing and distribution can be configured programmatically using replication
stored procedures.
-- This script uses sqlcmd scripting variables. They are in the form
-- $(MyVariable). For information about how to use scripting variables
-- on the command line and in SQL Server Management Studio, see the
-- "Executing Replication Scripts" section in the topic
-- "Programming Replication Using System Stored Procedures".
-- Install the Distributor and the distribution database.

DECLARE @distributor AS sysname;
DECLARE @distributionDB AS sysname;
DECLARE @publisher AS sysname;
DECLARE @directory AS nvarchar(500);
DECLARE @publicationDB AS sysname;
-- Specify the Distributor name.
SET @distributor = $(DistPubServer);
-- Specify the distribution database.
SET @distributionDB = N'distribution';
-- Specify the Publisher name.
SET @publisher = $(DistPubServer);
-- Specify the replication working directory.
SET @directory = N'\\' + $(DistPubServer) + '\repldata';
-- Specify the publication database.
SET @publicationDB = N'AdventureWorks2012';
-- Install the server MYDISTPUB as a Distributor using the defaults,

-- including autogenerating the distributor password.
USE master
EXEC sp_adddistributor @distributor = @distributor;
-- Create a new distribution database using the defaults, including

-- using Windows Authentication.
USE master
EXEC sp_adddistributiondb @database = @distributionDB,
@security_mode = 1;
GO
-- Create a Publisher and enable AdventureWorks2012 for replication.

-- Add MYDISTPUB as a publisher with MYDISTPUB as a local distributor
-- and use Windows Authentication.
-- Specify the distribution database.
-- Specify the Publisher name.
USE [distribution]
EXEC sp_adddistpublisher @publisher=@publisher,
@distribution_db=@distributionDB,
@security_mode = 1;
GO
Using Replication Management Objects (RMO)

To configure publishing and distribution on a single server
1. Create a connection to the server by using the ServerConnection class.
2. Create an instance of the ReplicationServer class. Pass the ServerConnection from step 1.
3. Create an instance of the DistributionDatabase class.
4. Set the Name property to the database name and set the ConnectionContext property to the
ServerConnection from step 1.
5. Install the Distributor by calling the InstallDistributor method. Pass the DistributionDatabase object from
step 3.
6. Create an instance of the DistributionPublisher class.
7. Set the following properties of DistributionPublisher:
Name - name of the Publisher.
ConnectionContext - the ServerConnection from step 1.
DistributionDatabase - the name of the database created in step 5.
WorkingDirectory - the share used to access snapshot files.
PublisherSecurity - the security mode used when connecting to the Publisher.
WindowsAuthentication is recommended.
8. Call the Create method.
To configure publishing and distribution using a remote Distributor
1. Create a connection to the remote Distributor server by using the ServerConnection class.
3. Create an instance of the DistributionDatabase class.
4. Set the Name property to the database name, and set the ConnectionContext property to the
ServerConnection from step 1.
5. Install the Distributor by calling the InstallDistributor method. Specify a secure password (used by the
Publisher when connecting to the remote Distributor) and the DistributionDatabase object from step 3.
For more information, see Secure the Distributor.
IMPORTANT!! When possible, prompt users to enter security credentials at runtime. If you must store
credentials, use the cryptographic services provided by the Microsoft Windows .NET Framework.
6. Create an instance of the DistributionPublisher class.

7. Set the following properties of DistributionPublisher:
Name - name of the local Publisher server.
ConnectionContext - the ServerConnection from step 1.
DistributionDatabase - the name of the database created in step 5.
WorkingDirectory - the share used to access snapshot files.
PublisherSecurity - the security mode used when connecting to the Publisher.
WindowsAuthentication is recommended.
9. Create a connection to the local Publisher server by using the ServerConnection class.
11. Call the InstallDistributor method. Pass the name of the remote Distributor and the password for the
remote Distributor specified in step 5.
IMPORTANT!! When possible, prompt users to enter security credentials at runtime. If you must store
credentials, use the cryptographic services provided by the Windows .NET Framework.
Example (RMO )
You can programmatically configure replication publishing and distribution by using Replication Management
Objects (RMO).
// Set the server and database names

string distributionDbName = "distribution";
string publisherName = publisherInstance;
string publicationDbName = "AdventureWorks2012";
DistributionDatabase distributionDb;
ReplicationServer distributor;
DistributionPublisher publisher;
ReplicationDatabase publicationDb;
// Create a connection to the server using Windows Authentication.

ServerConnection conn = new ServerConnection(publisherName);
try
{
// Connect to the server acting as the Distributor
// and local Publisher.
conn.Connect();
// Define the distribution database at the Distributor,

// but do not create it now.
distributionDb = new DistributionDatabase(distributionDbName, conn);
distributionDb.MaxDistributionRetention = 96;
distributionDb.HistoryRetention = 120;
// Set the Distributor properties and install the Distributor.

// This also creates the specified distribution database.
distributor = new ReplicationServer(conn);
distributor.InstallDistributor((string)null, distributionDb);
// Set the Publisher properties and install the Publisher.

publisher = new DistributionPublisher(publisherName, conn);
publisher.DistributionDatabase = distributionDb.Name;
publisher.WorkingDirectory = @"\\" + publisherName + @"\repldata";
publisher.PublisherSecurity.WindowsAuthentication = true;
publisher.Create();
// Enable AdventureWorks2012 as a publication database.

publicationDb = new ReplicationDatabase(publicationDbName, conn);
publicationDb.EnabledTransPublishing = true;
publicationDb.EnabledMergePublishing = true;
}
catch (Exception ex)
{
// Implement appropriate error handling here.
throw new ApplicationException("An error occured when installing distribution and publishing.", ex);
}
finally
{
conn.Disconnect();
}
' Set the server and database names
Dim distributionDbName As String = "distribution"
Dim publisherName As String = publisherInstance
Dim publicationDbName As String = "AdventureWorks2012"
Dim distributionDb As DistributionDatabase

Dim distributor As ReplicationServer
Dim publisher As DistributionPublisher
Dim publicationDb As ReplicationDatabase
' Create a connection to the server using Windows Authentication.

Dim conn As ServerConnection = New ServerConnection(publisherName)
Try
' Connect to the server acting as the Distributor
' and local Publisher.
conn.Connect()
' Define the distribution database at the Distributor,

' but do not create it now.
distributionDb = New DistributionDatabase(distributionDbName, conn)
distributionDb.MaxDistributionRetention = 96
distributionDb.HistoryRetention = 120
' Set the Distributor properties and install the Distributor.

' This also creates the specified distribution database.
distributor = New ReplicationServer(conn)
distributor.InstallDistributor((CType(Nothing, String)), distributionDb)
' Set the Publisher properties and install the Publisher.

publisher = New DistributionPublisher(publisherName, conn)
publisher.DistributionDatabase = distributionDb.Name
publisher.WorkingDirectory = "\\" + publisherName + "\repldata"
publisher.PublisherSecurity.WindowsAuthentication = True
publisher.Create()
' Enable AdventureWorks2012 as a publication database.

publicationDb = New ReplicationDatabase(publicationDbName, conn)
publicationDb.EnabledTransPublishing = True
publicationDb.EnabledMergePublishing = True
Catch ex As Exception
' Implement appropriate error handling here.
Throw New ApplicationException("An error occured when installing distribution and publishing.", ex)
Finally
conn.Disconnect()
End Try
See Also
Configure Replication for Always On Availability Groups (SQL Server)
View and Modify Distributor and Publisher
Properties
Data Warehouse
This topic describes how to view and modify Distributor and Publisher properties in SQL Server 2017 by using
SQL Server Management Studio, Transact-SQL, or Replication Management Objects (RMO).
In This Topic
Before you begin:
Recommendations
Security
To view and modify Distributor and Publisher properties, using:
SQL Server Management Studio
Transact-SQL
Replication Management Objects (RMO)
Before You Begin

Recommendations
For Publishers running versions prior to Microsoft SQL Server 2005, a user in the sysadmin fixed server
role can register Subscribers on the Subscribers page. Beginning with SQL Server 2005, it is no longer
necessary to explicitly register Subscribers for replication.
Security
When possible, prompt users to enter security credentials at runtime.

To view and modify Distributor properties
1. Connect to the Distributor in SQL Server Management Studio, and then expand the server node.
2. Right-click the Replication folder, and then click Distributor Properties.
3. View and modify properties in the Distributor Properties - <Distributor> dialog box.
To view and modify properties for a distribution database, click the properties button (...) for the
database on the General page of thedialog box.
To view and modify Publisher properties associated with the Distributor, click the properties
button (...) for the Publisher on the Publishers page of the dialog box.
To access profiles for replication agents, click the Profile Defaults button on the General page of
the dialog box. For more information, see Replication Agent Profiles.
To change the password for the account used when administrative stored procedures execute at
the Publisher and update information at the Distributor, enter a new password in the Password
and Confirm password boxes on the Publishers page of the dialog box. For more information,
see Secure the Distributor.
4. Modify any properties if necessary, and then click OK.
To view and modify Publisher properties
1. Connect to the Publisher in SQL Server Management Studio, and then expand the server node.
2. Right-click the Replication folder, and then click Publisher Properties.
3. View and modify properties in the Publisher Properties - < Publisher > dialog box.
A user in the sysadmin fixed server role can enable databases for replication on the Publication
Databases page. Enabling a database does not publish that database; rather, it allows any user in the
db_owner fixed database role for that database to create one or more publications in the database.
Using Transact-SQL
Publisher and Distributor properties can be viewed programmatically using replication stored procedures.
To view Distributor and distribution database properties
1. Execute sp_helpdistributor to return information about the Distributor, distribution database, and
working directory.
2. Execute sp_helpdistributiondb to return properties of a specified distribution database.
To change Distributor and distribution database properties
1. At the Distributor, execute sp_changedistributor_property to modify Distributor properties.
2. At the Distributor, execute sp_changedistributiondb to modify distribution database properties.
3. At the Distributor, execute sp_changedistributor_password to change the Distributor password.
IMPORTANT
When possible, prompt users to enter security credentials at runtime. If you must store credentials in a script file,
secure the file to prevent unauthorized access.
4. At the Distributor, execute sp_changedistpublisher to change the properties of a Publisher using the
Distributor.
Examples (Transact-SQL )
The following example Transact-SQL script returns information about the Distributor and distribution database.
-- View information about the Distributor, distribution database,

-- working directory, and SQL Server Agent user account.
USE master
EXEC sp_helpdistributor;
GO
-- View information about the specified distribution database.

USE distribution
EXEC sp_helpdistributiondb;
GO
This example changes retention periods for the Distributor, the password used when connecting to the
Distributor, and the interval at which the Distributor checks the status of various replication agents (also known
as the heartbeat interval).
IMPORTANT
When possible, prompt users to enter security credentials at runtime. If you must store credentials in a script file, secure
the file to prevent unauthorized access.
-- Change the heartbeat interval at the Distributor to 5 minutes.

USE master
exec sp_changedistributor_property
@property = N'heartbeat_interval',
@value = 5;
GO

-- Change the history retention period to 24 hours and the

-- maximum retention period to 48 hours.
USE distribution
EXEC sp_changedistributiondb @distributionDB, N'history_retention', 24
EXEC sp_changedistributiondb @distributionDB, N'max_distretention', 48
GO
-- Change the password on the Distributor.

-- To avoid storing the password in the script file, the value is passed
-- into SQLCMD as a scripting variable. For information about how to use
-- scripting variables on the command line and in SQL Server Management
-- Studio, see the "Executing Replication Scripts" section in the topic
USE master
EXEC sp_changedistributor_password $(Password)
GO

To view and modify Distributor properties
1. Create a connection to the Distributor by using the ServerConnection class.
2. Create an instance of the ReplicationServer class. Pass the ServerConnection object from step 1.
3. (Optional) Check the IsDistributor property to verify that the currently connected server is a Distributor.
4. Call the Load method to get the properties from the server.
5. (Optional) To change properties, set a new value for one or more of the Distributor properties that can be
set on the ReplicationServer object.
6. (Optional) If the CachePropertyChanges property on the ReplicationServer object is set to true, call the
CommitPropertyChanges method to commit the changes to the server.
To view and modify distribution database properties
2. Create an instance of the DistributionDatabase class. Specify the name property and pass the
ServerConnection object from step 1.
3. Call the LoadProperties method to get the properties from the server. If this method returns false, the
database with the specified name does not exist on the server.
4. (Optional) To change properties, set a new value for one of the DistributionDatabase properties that can
be set.
5. (Optional) If the CachePropertyChanges property on the DistributionDatabase object is set to true, call
the CommitPropertyChanges method to commit the changes to the server.
To view and modify Publisher properties
1. Create a connection to the Publisher by using the ServerConnection class.
2. Create an instance of the DistributionPublisher class. Specify the Name property and pass the
3. (Optional) To change properties, set a new value for one of the DistributionPublisher properties that can
be set.
4. (Optional) If the CachePropertyChanges property on the DistributionPublisher object is set to true, call
the CommitPropertyChanges method to commit the changes to the server.
To change the password for the administrative connection from the Publisher to the Distributor
2. Create an instance of the ReplicationServer class.
3. Set the ConnectionContext property to the connection created in step 1.
4. Call the Load method to get the properties of the object.
5. Call the ChangeDistributorPassword method. Pass the new password value for the password parameter.
IMPORTANT
When possible, prompt users to enter security credentials at runtime. If you must store credentials, use the
cryptographic services provided by the Microsoft Windows .NET Framework.
6. (Optional) Perform the following steps to change the password at each remote Publisher that uses this
Distributor:
a. Create a connection to the Publisher by using the ServerConnection class.
b. Create an instance of the ReplicationServer class.
c. Set the ConnectionContext property to the connection created in step 6a.
d. Call the Load method to get the properties of the object.
e. Call the ChangeDistributorPassword method. Pass the new password value from Step 5 for the
password parameter.
Example (RMO )
This example shows how to change Distribution and distribution database properties.
IMPORTANT
To avoid storing credentials in the code, the new Distributor password is supplied at runtime.
// Set the Distributor and distribution database names.
string distributorName = publisherInstance;
DistributionDatabase distributionDb;
// Create a connection to the Distributor using Windows Authentication.

ServerConnection conn = new ServerConnection(distributorName);
try
{
// Open the connection.
conn.Connect();
distributor = new ReplicationServer(conn);
// Load Distributor properties, if it is installed.

if (distributor.LoadProperties())
{
// Password supplied at runtime.
distributor.ChangeDistributorPassword(password);
distributor.AgentCheckupInterval = 5;
// Save changes to the Distributor properties.

distributor.CommitPropertyChanges();
}
else
{
throw new ApplicationException(
String.Format("{0} is not a Distributor.", publisherInstance));
}
// Create an object for the distribution database

// using the open Distributor connection.
distributionDb = new DistributionDatabase(distributionDbName, conn);
// Change distribution database properties.

if (distributionDb.LoadProperties())
{
// Change maximum retention period to 48 hours and history retention
// period to 24 hours.
distributionDb.MaxDistributionRetention = 48;
distributionDb.HistoryRetention = 24;
// Save changes to the distribution database properties.

distributionDb.CommitPropertyChanges();
}
else
{
// Do something here if the distribution database does not exist.
}
}
{
// Implement the appropriate error handling here.
throw new ApplicationException("An error occured when changing Distributor " +
" or distribution database properties.", ex);
}
finally
{
conn.Disconnect();
}
' Set the Distributor and distribution database names.
Dim distributorName As String = publisherInstance

' Create a connection to the Distributor using Windows Authentication.

Dim conn As ServerConnection = New ServerConnection(distributorName)
Try
' Open the connection.
conn.Connect()
distributor = New ReplicationServer(conn)
' Load Distributor properties, if it is installed.

If distributor.LoadProperties() Then
' Password supplied at runtime.
distributor.ChangeDistributorPassword(password)
distributor.AgentCheckupInterval = 5
' Save changes to the Distributor properties.

distributor.CommitPropertyChanges()
Else
Throw New ApplicationException( _
String.Format("{0} is not a Distributor.", publisherInstance))
End If
' Create an object for the distribution database

' using the open Distributor connection.
distributionDb = New DistributionDatabase(distributionDbName, conn)
' Change distribution database properties.

If distributionDb.LoadProperties() Then
' Change maximum retention period to 48 hours and history retention
' period to 24 hours.
distributionDb.MaxDistributionRetention = 48
distributionDb.HistoryRetention = 24
' Save changes to the distribution database properties.

distributionDb.CommitPropertyChanges()
Else
' Do something here if the distribution database does not exist.
End If
' Implement the appropriate error handling here.
Throw New ApplicationException("An error occured when changing Distributor " + _
" or distribution database properties.", ex)
Finally
conn.Disconnect()
End Try
See Also
Distributor and Publisher Information Script
View Information and Perform Tasks for a Publisher (Replication Monitor)
Warehouse
This topic describes how to disable publishing and distribution in SQL Server 2017 by using SQL Server
Management Studio, Transact-SQL, or Replication Management Objects (RMO).
You can do the following:
Delete all distribution databases on the Distributor.
Disable all Publishers that use the Distributor and delete all publications on those Publishers.
Delete all subscriptions to the publications. Data in the publication and subscription databases will not be
deleted; however, it loses its synchronization relationship to any publication databases. If you want the data
at the Subscriber to be deleted, you must delete it manually.
In This Topic
Before you begin:
Prerequisites
To disable publishing and distribution, using:
Transact-SQL
Before You Begin

Prerequisites
To disable publishing and distribution, all distribution and publication databases must be online. If any
database snapshots exist for distribution or publication databases, they must be dropped before disabling
publishing and distribution. A database snapshot is a read-only offline copy of a database and is not related to a
replication snapshot. For more information, see Database Snapshots (SQL Server).

Disable publishing and distribution by using the Disable Publishing and Distribution Wizard.
To disable publishing and distribution
1. Connect to the Publisher or Distributor you want to disable in Microsoft SQL Server Management Studio,
and then expand the server node.
2. Right-click the Replication folder, and then click Disable Publishing and Distribution.
3. Complete the steps in the Disable Publishing and Distribution Wizard.
Using Transact-SQL
Publishing and distributing can be disabled programmatically using replication stored procedures.
1. Stop all replication-related jobs. For a list of job names, see the "Agent Security Under SQL Server Agent"
section of Replication Agent Security Model.
2. At each Subscriber on the subscription database, execute sp_removedbreplication to remove replication
objects from the database. This stored procedure will not remove replication jobs at the Distributor.
3. At the Publisher on the publication database, execute sp_removedbreplication to remove replication objects
from the database.
4. If the Publisher uses a remote Distributor, execute sp_dropdistributor.
5. At the Distributor, execute sp_dropdistpublisher. This stored procedure should be run once for each
Publisher registered at the Distributor.
6. At the Distributor, execute sp_dropdistributiondb to delete the distribution database. This stored procedure
should be run once for each distribution database at the Distributor. This also removes any Queue Reader
Agent jobs associated with the distribution database.
7. At the Distributor, execute sp_dropdistributor to remove the Distributor designation from the server.
NOTE
If all replication publishing and distribution objects are not dropped before you execute sp_dropdistpublisher and
sp_dropdistributor, these procedures will return an error. To drop all replication-related objects when a Publisher or
Distributor is dropped, the @no_checks parameter must be set to 1. If a Publisher or Distributor is offline or
unreachable, the @ignore_distributor parameter can be set to 1 so that they can be dropped; however, any
publishing and distributing objects left behind must be removed manually.
This example script removes replication objects from the subscription database.
-- Remove replication objects from the subscription database on MYSUB.

DECLARE @subscriptionDB AS sysname
SET @subscriptionDB = N'AdventureWorks2012Replica'
-- Remove replication objects from a subscription database (if necessary).

USE master
EXEC sp_removedbreplication @subscriptionDB
GO
This example script disables publishing and distribution on a server that is a Publisher and Distributor and drops
the distribution database.
-- Disable publishing and distribution.

DECLARE @publicationDB as sysname;
-- Disable the publication database.

USE [AdventureWorks2012]
EXEC sp_removedbreplication @publicationDB;
-- Remove the registration of the local Publisher at the Distributor.

USE master
EXEC sp_dropdistpublisher @publisher;
-- Delete the distribution database.

EXEC sp_dropdistributiondb @distributionDB;
-- Remove the local server as a Distributor.

EXEC sp_dropdistributor;
GO

1. Remove all subscriptions to publications that use the Distributor. For more information, see Delete a Pull
Subscription and Delete a Push Subscription.
2. Remove all publications that use the Distributor, and disable publishing for all databases if the Publisher
and Distributor are on the same server. For more information, see Delete a Publication.
4. Create an instance of the DistributionPublisher class. Specify the Name property, and pass the
5. (Optional) Call the LoadProperties method to get the properties of the object and verify that the Publisher
exists. If this method returns false, the Publisher name set in step 4 was incorrect or the Publisher is not
used by this Distributor.
6. Call the Remove method. Pass a value of true for force if the Publisher and Distributor are on different
servers, and when the Publisher should be uninstalled at the Distributor without first verifying that
publications no longer exist at the Publisher.
7. Create an instance of the ReplicationServer class. Pass the ServerConnection object from step 3.
8. Call the UninstallDistributor method. Pass a value of true for force to remove all replication objects at the
Distributor without first verifying that all local publication databases have been disabled, and distribution
databases have been uninstalled.
Examples (RMO )
This example removes the Publisher registration at the Distributor, drops the distribution database, and uninstalls
the Distributor.
// Set the Distributor and publication database names.
// Publisher and Distributor are on the same server instance.
// Create connections to the Publisher and Distributor

// using Windows Authentication.
ServerConnection publisherConn = new ServerConnection(publisherName);
ServerConnection distributorConn = new ServerConnection(distributorName);
// Create the objects we need.

ReplicationServer distributor =
new ReplicationServer(distributorConn);
DistributionPublisher publisher;
DistributionDatabase distributionDb =
new DistributionDatabase(distributionDbName, distributorConn);
publicationDb = new ReplicationDatabase(publicationDbName, publisherConn);
try
{
// Connect to the Publisher and Distributor.
publisherConn.Connect();
distributorConn.Connect();
// Disable all publishing on the AdventureWorks2012 database.

if (publicationDb.LoadProperties())
{
if (publicationDb.EnabledMergePublishing)
{
publicationDb.EnabledMergePublishing = false;
}
else if (publicationDb.EnabledTransPublishing)
{
publicationDb.EnabledTransPublishing = false;
}
}
else
{
String.Format("The {0} database does not exist.", publicationDbName));
}
// We cannot uninstall the Publisher if there are still Subscribers.

if (distributor.RegisteredSubscribers.Count == 0)
{
// Uninstall the Publisher, if it exists.
publisher = new DistributionPublisher(publisherName, distributorConn);
if (publisher.LoadProperties())
{
publisher.Remove(false);
}
else
{
// Do something here if the Publisher does not exist.
throw new ApplicationException(String.Format(
"{0} is not a Publisher for {1}.", publisherName, distributorName));
}
// Drop the distribution database.

if (distributionDb.LoadProperties())
{
distributionDb.Remove();
}
else
{
// Do something here if the distribition DB does not exist.
// Do something here if the distribition DB does not exist.
"The distribution database '{0}' does not exist on {1}.",
distributionDbName, distributorName));
}
// Uninstall the Distributor, if it exists.

if (distributor.LoadProperties())
{
// Passing a value of false means that the Publisher
// and distribution databases must already be uninstalled,
// and that no local databases be enabled for publishing.
distributor.UninstallDistributor(false);
}
else
{
//Do something here if the distributor does not exist.
"The Distributor '{0}' does not exist.", distributorName));
}
}
else
{
throw new ApplicationException("You must first delete all subscriptions.");
}
}
{
throw new ApplicationException("The Publisher and Distributor could not be uninstalled", ex);
}
finally
{
publisherConn.Disconnect();
distributorConn.Disconnect();
}
' Set the Distributor and publication database names.

' Publisher and Distributor are on the same server instance.
Dim distributorName As String = subscriberInstance
' Create connections to the Publisher and Distributor

' using Windows Authentication.
Dim publisherConn As ServerConnection = New ServerConnection(publisherName)
Dim distributorConn As ServerConnection = New ServerConnection(distributorName)
' Create the objects we need.

distributor = New ReplicationServer(distributorConn)
Dim publisher As DistributionPublisher
distributionDb = New DistributionDatabase(distributionDbName, distributorConn)
publicationDb = New ReplicationDatabase(publicationDbName, publisherConn)
Try
' Connect to the Publisher and Distributor.
publisherConn.Connect()
distributorConn.Connect()
' Disable all publishing on the AdventureWorks2012 database.

If publicationDb.LoadProperties() Then
If publicationDb.EnabledMergePublishing Then
publicationDb.EnabledMergePublishing = False
ElseIf publicationDb.EnabledTransPublishing Then
ElseIf publicationDb.EnabledTransPublishing Then
publicationDb.EnabledTransPublishing = False
End If
Else
String.Format("The {0} database does not exist.", publicationDbName))
End If
' We cannot uninstall the Publisher if there are still Subscribers.

If distributor.RegisteredSubscribers.Count = 0 Then
' Uninstall the Publisher, if it exists.
publisher = New DistributionPublisher(publisherName, distributorConn)
If publisher.LoadProperties() Then
publisher.Remove(False)
Else
' Do something here if the Publisher does not exist.
Throw New ApplicationException(String.Format( _
"{0} is not a Publisher for {1}.", publisherName, distributorName))
End If
' Drop the distribution database.

If distributionDb.LoadProperties() Then
distributionDb.Remove()
Else
' Do something here if the distribition DB does not exist.
"The distribution database '{0}' does not exist on {1}.", _
distributionDbName, distributorName))
End If
' Uninstall the Distributor, if it exists.

If distributor.LoadProperties() Then
' Passing a value of false means that the Publisher
' and distribution databases must already be uninstalled,
' and that no local databases be enabled for publishing.
distributor.UninstallDistributor(False)
Else
'Do something here if the distributor does not exist.
"The Distributor '{0}' does not exist.", distributorName))
End If
Else
Throw New ApplicationException("You must first delete all subscriptions.")
End If
Throw New ApplicationException("The Publisher and Distributor could not be uninstalled", ex)
Finally
publisherConn.Disconnect()
distributorConn.Disconnect()
End Try
This example uninstalls the Distributor without first disabling local publication databases or dropping the
// Set the Distributor and publication database names.
// Publisher and Distributor are on the same server instance.
// Create connections to the Distributor

// using Windows Authentication.
ServerConnection conn = new ServerConnection(distributorName);
conn.DatabaseName = "master";
// Create the objects we need.

ReplicationServer distributor = new ReplicationServer(conn);
try
{
// Connect to the Publisher and Distributor.
conn.Connect();
// Uninstall the Distributor, if it exists.

// Use the force parameter to remove everthing.
if (distributor.IsDistributor && distributor.LoadProperties())
{
// Passing a value of true means that the Distributor
// is uninstalled even when publishing objects, subscriptions,
// and distribution databases exist on the server.
distributor.UninstallDistributor(true);
}
else
{
//Do something here if the distributor does not exist.
}
}
{
throw new ApplicationException("The Publisher and Distributor could not be uninstalled", ex);
}
finally
{
conn.Disconnect();
}
' Set the Distributor and publication database names.
' Publisher and Distributor are on the same server instance.
' Create connections to the Distributor

' using Windows Authentication.
Dim conn As ServerConnection = New ServerConnection(distributorName)
conn.DatabaseName = "master"
' Create the objects we need.

Dim distributor As ReplicationServer = New ReplicationServer(conn)
Try
' Connect to the Publisher and Distributor.
conn.Connect()
' Uninstall the Distributor, if it exists.

' Use the force parameter to remove everthing.
If distributor.IsDistributor And distributor.LoadProperties() Then
' Passing a value of true means that the Distributor
' is uninstalled even when publishing objects, subscriptions,
' and distribution databases exist on the server.
distributor.UninstallDistributor(True)
Else
'Do something here if the distributor does not exist.
End If
Throw New ApplicationException("The Publisher and Distributor could not be uninstalled", ex)
Finally
conn.Disconnect()
End Try
See Also
Enable a Database for Replication (SQL Server
Management Studio)
Warehouse
A database is implicitly enabled for replication when a member of the sysadmin fixed server role creates a
publication with the New Publication Wizard. A member of the sysadmin fixed server role can also enable a
database for replication explicitly, so that a member of the db_owner fixed database role can create one or more
publications in that database. To enable a database explicitly, use the Publication Databases page of the
Publisher Properties - <Publisher> dialog box. For more information about accessing this dialog box, see Create
a Publication.
To enable a database for replication
1. On the Publication Databases page of the Publisher Properties - <Publisher> dialog box, select the
Transactional and/or Merge check box for each database you want to replicate. Select Transactional to
enable the database for snapshot replication.
2. Click OK.
Enable a Remote Publisher at a Distributor (SQL
Warehouse
Enable a Publisher to use a remote Distributor on the Publishers page. This page is available in the Configure
Distribution Wizard and the Distributor Properties - <Distributor> dialog box. For more information about
using the wizard and accessing the dialog box, see Configure Publishing and Distribution and View and Modify
Distributor and Publisher Properties.
To enable a Publisher in the Configure Distribution Wizard
1. On the Publishers page of the Configure Distribution Wizard, click Add.
2. Click Add SQL Server Publisher. For information about enabling an Oracle Publisher to use a Distributor,
see Create a Publication from an Oracle Database.
3. In the Connect to Server dialog box, specify connection information for the Publisher that will use the
remote Distributor, and then click Connect.
4. On the Distributor Password page, in the Password and Confirm password text boxes, specify a strong
password for the distributor_admin account, which replication uses to connect from the Publisher to the
Distributor to perform administrative tasks.
5. To view and modify settings for a Publisher, click the properties button ().
6. Click OK.
To enable a Publisher in the Distributor Properties dialog box
1. On the Publishers page of the Distributor Properties - <Distributor> dialog box, click Add.
2. Click Add SQL Server Publisher. For information about enabling an Oracle Publisher to use a Distributor,
see Create a Publication from an Oracle Database.
3. In the Connect to Server dialog box, specify connection information for the Publisher that will use the
remote Distributor, and then click Connect.
4. On the Publishers page, in the Password and Confirm password text boxes, specify a strong password for
the distributor_admin account, which replication uses to connect from the Publisher to the Distributor to
perform administrative tasks.
5. To view and modify settings for a Publisher, click the properties button ().
6. Click OK.
See Also
Secure the Distributor
Specify the Default Snapshot Location (SQL Server
Management Studio)
Warehouse
Specify the default snapshot location on the Snapshot Folder page of the Configure Distribution Wizard. For
more information about using this wizard, see Configure Publishing and Distribution. If you create a publication on
a server that is not configured as a Distributor, specify a default snapshot location on the Snapshot Folder page
of the New Publication Wizard. For more information about using this wizard, see Create a Publication.
Modify the default snapshot location on the Publishers page of the Distributor Properties - <Distributor>
dialog box. For more information, see View and Modify Distributor and Publisher Properties. Set the snapshot
folder for each publication in the Publication Properties - <Publication> dialog box. For more information, see
View and Modify Publication Properties.
To modify the default snapshot location
1. On the Publishers page of the Distributor Properties - <Distributor> dialog box, click the properties
button () for the Publisher for which you want to change the default snapshot location.
2. In the Publisher Properties - <Publisher> dialog box, enter a value for the Default Snapshot Folder
property.
NOTE
The Snapshot Agent must have write permissions for the directory you specify, and the Distribution Agent or Merge
Agent must have read permissions. If pull subscriptions are used, you must specify a shared directory as a universal
naming convention (UNC) path, such as \\computername\snapshot. For more information, see Secure the Snapshot
Folder.
3. Click OK.
See Also
Alternate Snapshot Folder Locations
Set Distribution Retention Period for Transactional
Publications
Warehouse
Specify the minimum distribution retention period and maximum distribution retention period on the Distribution
Database Properties - <DistributionDatabase> dialog box. This is available from the General page of the
Distributor Properties - <Distributor> dialog box. For more information about accessing this dialog box, see
View and Modify Distributor and Publisher Properties.
To specify the distribution retention period
1. On the General page of the Distributor Properties - <Distributor> dialog box, click the properties button
() for the distribution database.
2. To specify the minimum distribution retention period, enter a value in the At least box; to specify the
maximum distribution retention period, enter a value in the But not more than box.
3. Click OK.
See Also
Set the History Retention Period (SQL Server
Management Studio)
Warehouse
Specify the history retention period on the General page of the Distribution Database Properties -
<DistributionDatabase> dialog box. This setting controls how long replication agent history is stored. This page
is available from the General page of the Distributor Properties - <Distributor> dialog box. For more
information about accessing this dialog box, see View and Modify Distributor and Publisher Properties.
To specify the history retention period
1. On the General page of the Distributor Properties - <Distributor> dialog box, click the properties button
() for the distribution database.
2. Enter a value in the Store replication performance history at least box.
3. Click OK.
See Also
Data Warehouse
A subscription is a request for a copy of the data and database objects in a publication. A subscription defines
which publication will be received, and where and when it will be received. When planning for subscriptions,
consider where you want agent processing to occur. The type of subscription you choose controls where the
agent runs. With a push subscription, the Merge Agent or Distribution Agent runs at the Distributor, whereas
with a pull subscription, agents run at the Subscribers. After a subscription is created, it cannot be changed
from one type to another.
SUBSCRIPTION CHARACTERISTICS USE WHEN
Push Subscription With a push subscription, the Data will typically be synchronized
Publisher propagates changes to a continuously or on a frequently
Subscriber without a request from the recurring schedule.
Subscriber. Changes can be pushed to
Subscribers on demand, continuously, Publications require near real-time
or on a scheduled basis. The movement of data.
Distribution Agent or Merge Agent
runs at the Distributor. The higher processor overhead at the
Distributor does not affect
performance.
Most often used with snapshot and

transactional replication.
Pull Subscription With a pull subscription, the Data will typically be synchronized on
Subscriber requests changes made at demand or on a schedule rather than
the Publisher. Pull subscriptions allow continuously.
the user at the Subscriber to
determine when the data changes are The publication has a large number of
synchronized. The Distribution Agent Subscribers, and/or it would be too
or the Merge Agent runs at the resource-intensive to run all the
Subscriber. agents at the Distributor.
Subscribers are autonomous,

disconnected, and/or mobile.
Subscribers will determine when they
will connect and synchronize changes.
Most often used with merge

replication.
Merge Replication Subscription Types

All replication types allow push and pull subscriptions. Merge replication uses two additional terms to
distinguish subscriptions: client subscriptions and server subscriptions. Both client and server subscription
types can be used with push and pull subscriptions. Client subscriptions are appropriate for most Subscribers,
whereas server subscriptions are typically used for Subscribers that republish data to other Subscribers.
Subscription choice also affects conflict resolution.
Non-SQL Server Subscribers
Oracle and IBM DB2 can subscribe to snapshot and transactional publications using push subscriptions. For
more information, see Non-SQL Server Subscribers.
Creating Subscriptions
To create a subscription, you supply the following information:
The name of the publication.
The name of the Subscriber and the subscription database.
Whether the Distribution Agent or Merge Agent runs at the Distributor or at the Subscriber.
Whether the Distribution Agent or Merge Agent runs continuously, on a scheduled basis, or on
demand only.
Whether the Snapshot Agent should create an initial snapshot for the subscription and whether the
Distribution Agent or Merge Agent should apply that snapshot at the Subscriber.
Accounts under which the Distribution Agent or Merge Agent will run.
For merge replication, the type of subscription: server or client.
To create a push subscription
To view or modify push subscription properties
To delete a push subscription
SQL Server Management Studio: Delete a Push Subscription
NOTE
Deleting a subscription does not remove published objects from the Subscriber.
To create a pull subscription

SQL Server Management Studio: Create a Pull Subscription
To view or modify pull subscription properties
To delete a pull subscription
See Also
Secure the Subscriber
Data Warehouse
This topic describes how create a pull subscription in SQL Server 2017 by using SQL Server Management
Studio, Transact-SQL, or Replication Management Objects (RMO).
Setting up a pull subscription for P2P replication is possible by script, but is not available through the wizard.

Create a pull subscription at the Publisher or the Subscriber using the New Subscription Wizard. Follow the
pages in the wizard to:
Specify the Publisher and publication.
Select where replication agents will run. For a pull subscription, select Run each agent at its
Subscriber (pull subscriptions) on the Distribution Agent Location page or Merge Agent
Location page, depending on the type of publication.
Specify Subscribers and subscription databases.
Specify the logins and passwords used for connections made by replication agents:
For subscriptions to snapshot and transactional publications, specify credentials on the
Distribution Agent Security page.
For subscriptions to merge publications, specify credentials on the Merge Agent Security page.
For information about the permissions required by each agent, see Replication Agent Security
Model.
Specify a synchronization schedule and when the Subscriber should be initialized.
Specify additional options for merge publications: subscription type; values for parameterized filtering;
and information for synchronization through HTTPS if the publication is enabled for Web
synchronization.
Specify additional options for transactional publications that allow updating subscriptions: whether
Subscribers should commit changes at the Publisher immediately or write them to a queue; credentials
used to connect from the Subscriber to the Publisher.
Optionally script the subscription.
To create a pull subscription from the Publisher
1. Connect to the Publisher in Microsoft SQL Server Management Studio, and then expand the server node.
2. Expand the Replication folder, and then expand the Local Publications folder.
3. Right-click the publication for which you want to create one or more subscriptions, and then click New
Subscriptions.
4. Complete the pages in the New Subscription Wizard.
To create a pull subscription from the Subscriber
1. Connect to the Subscriber in SQL Server Management Studio, and then expand the server node.
2. Expand the Replication folder.
3. Right-click the Local Subscriptions folder, and then click New Subscriptions.
4. On the Publication page of the New Subscription Wizard, select <Find SQL Server Publisher> or
<Find Oracle Publisher> from the Publisher drop-down list.
5. Connect to the Publisher in the Connect to Server dialog box.
6. Select a publication on the Publication page.
Using Transact-SQL
Pull subscriptions can be created programmatically using replication stored procedures. The stored procedures
used will depend on the type of publication to which the subscription belongs.
To create a pull subscription to a snapshot or transactional publication
1. At the Publisher, verify that the publication supports pull subscriptions by executing sp_helppublication
(Transact-SQL).
If the value of allow_pull in the result set is 1, then the publication supports pull subscriptions.
If the value of allow_pull is 0, execute sp_changepublication (Transact-SQL), specifying
allow_pull for @property and true for @value.
2. At the Subscriber, execute sp_addpullsubscription (Transact-SQL). Specify @publisher and
@publication. For information about updating subscriptions, see Create an Updatable Subscription to a
Transactional Publication.
3. At the Subscriber, execute sp_addpullsubscription_agent (Transact-SQL). Specify the following:
The @publisher, @publisher_db, and @publication parameters.
The Microsoft Windows credentials under which the Distribution Agent at the Subscriber runs for
@job_login and @job_password.
NOTE
Connections made using Windows Integrated Authentication always use the Windows credentials
specified by @job_login and @job_password. The Distribution Agent always makes the local connection
to the Subscriber using Windows Integrated Authentication. By default, the agent will connect to the
Distributor using Windows Integrated Authentication.
(Optional) A value of 0 for @distributor_security_mode and the SQL Server login information
for @distributor_login and @distributor_password, if you need to use SQL Server
Authentication when connecting to the Distributor.
A schedule for the Distribution Agent job for this subscription. For more information, see Specify
Synchronization Schedules.
4. At the Publisher, execute sp_addsubscription (Transact-SQL) to register the pull subscription. Specify
@publication, @subscriber, and @destination_db. Specify a value of pull for @subscription_type.
To create a pull subscription to a merge publication
1. At the Publisher, verify that the publication supports pull subscriptions by executing
sp_helpmergepublication (Transact-SQL).
If the value of allow_pull in the result set is 1, then the publication supports pull subscriptions.
If the value of allow_pull is 0, execute sp_changemergepublication (Transact-SQL), specifying
allow_pull for @property and true for @value.
2. At the Subscriber, execute sp_addmergepullsubscription (Transact-SQL). Specify @publisher,
@publisher_db, @publication, and the following parameters:
@subscriber_type specify local for a client subscription and global for a server subscription.
@subscription_priority Specify a priority for the subscription (0.00 to 99.99). This is only
required for a server subscription.
For more information, see Advanced Merge Replication Conflict Detection and Resolution.
3. At the Subscriber, execute sp_addmergepullsubscription_agent (Transact-SQL). Specify the following
parameters:
@publisher, @publisher_db, and @publication.
The Windows credentials under which the Merge Agent at the Subscriber runs for @job_login
and @job_password.
NOTE
Connections made using Windows Integrated Authentication always use the Windows credentials
specified by @job_login and @job_password. The Merge Agent always makes the local connection to
the Subscriber using Windows Integrated Authentication. By default, the agent will connect to the
Distributor and Publisher using Windows Integrated Authentication.
(Optional) A value of 0 for @distributor_security_mode and the SQL Server login information
for @distributor_login and @distributor_password, if you need to use SQL Server
Authentication when connecting to the Distributor.
(Optional) A value of 0 for @publisher_security_mode and the SQL Server login information for
@publisher_login and @publisher_password, if you need to use SQL Server Authentication
when connecting to the Publisher.
A schedule for the Merge Agent job for this subscription. For more information, see Create an
Updatable Subscription to a Transactional Publication.
4. At the Publisher, execute sp_addmergesubscription (Transact-SQL). Specify @publication,
@subscriber, @subscriber_db, and a value of pull for @subscription_type. This registers the pull
subscription.
The following example creates a pull subscription to a transactional publication. The first batch is executed at
the Subscriber, and the second batch is executed at the Publisher. Login and password values are supplied at
runtime using sqlcmd scripting variables.
-- Execute this batch at the Subscriber.

DECLARE @publication AS sysname;
SET @publication = N'AdvWorksProductTran';
SET @publisher = $(PubServer);
SET @publicationDB = N'AdventureWorks';
-- At the subscription database, create a pull subscription

-- to a transactional publication.
USE [AdventureWorksReplica]
EXEC sp_addpullsubscription
@publisher = @publisher,
@publication = @publication,
@publisher_db = @publicationDB;
-- Add an agent job to synchronize the pull subscription.

EXEC sp_addpullsubscription_agent
@publisher_db = @publicationDB,
@distributor = @publisher,
@job_login = $(Login),
@job_password = $(Password);
GO
-- Execute this batch at the Publisher.

DECLARE @subscriber AS sysname;
DECLARE @subscriptionDB AS sysname;
SET @subscriber = $(SubServer);
SET @subscriptionDB = N'AdventureWorksReplica';
-- At the Publisher, register the subscription, using the defaults.

EXEC sp_addsubscription
@subscriber = @subscriber,
@destination_db = @subscriptionDB,
@subscription_type = N'pull',
@status = N'subscribed';
GO
The following example creates a pull subscription to a merge publication. The first batch is executed at the
Subscriber, and the second batch is executed at the Publisher. Login and password values are supplied at
runtime using sqlcmd scripting variables.
-- Execute this batch at the Subscriber.

DECLARE @hostname AS sysname;
SET @publication = N'AdvWorksSalesOrdersMerge';
SET @publicationDB = N'AdventureWorks';
SET @hostname = N'adventure-works\david8';
-- At the subscription database, create a pull subscription

-- to a merge publication.
USE [AdventureWorksReplica]
EXEC sp_addmergepullsubscription
@publisher_db = @publicationDB;
-- Add an agent job to synchronize the pull subscription.

EXEC sp_addmergepullsubscription_agent
@distributor = @publisher,
@job_password = $(Password),
@hostname = @hostname;
GO
-- Execute this batch at the Publisher.

DECLARE @myMergePub AS sysname;
DECLARE @mySub AS sysname;
DECLARE @mySubDB AS sysname;
SET @myMergePub = N'AdvWorksSalesOrdersMerge';

SET @mySub = N'MYSUBSERVER';
SET @mySubDB = N'AdventureWorksReplica';
-- At the Publisher, register the subscription, using the defaults.

USE [AdventureWorks]
EXEC sp_addmergesubscription @publication = @myMergePub,
@subscriber = @mySub, @subscriber_db = @mySubDB,
@subscription_type = N'pull';
GO

The RMO classes used to create a pull subscription depend on the type of publication to which the subscription
belongs.
To create a pull subscription to a snapshot or transactional publication
1. Create connections to both the Subscriber and Publisher by using the ServerConnection Class.
2. Create an instance of the TransPublication class by using the Publisher connection from step 1. Specify
Name, DatabaseName and ConnectionContext.
3. Call the LoadProperties method. If this method returns false, either the properties specified in step 2 are
incorrect or the publication does not exist on the server.
4. Perform a bitwise logical AND (& in Visual C# and And in Visual Basic) between the Attributes property
and AllowPull. If the result is None, set Attributes to the result of a bitwise logical OR (| in Visual C# and
Or in Visual Basic) between Attributes and AllowPull. Then, call CommitPropertyChanges to enable pull
subscriptions.
5. If the subscription database does not exist, create it by using the Database class. For more information,
see Creating, Altering, and Removing Databases.
6. Create an instance of the TransPullSubscription class.
7. Set the following subscription properties:
The ServerConnection to the Subscriber created in step 1 for ConnectionContext.
Name of the subscription database for DatabaseName.
Name of the Publisher for PublisherName.
Name of the publication database for PublicationDBName.
Name of the publication for PublicationName.
The Login and Password fields of SynchronizationAgentProcessSecurity to provide the credentials
for the Microsoft Windows account under which the Distribution Agent runs at the Subscriber.
This account is used to make local connections to the Subscriber and to make remote connections
using Windows Authentication.
NOTE
Setting SynchronizationAgentProcessSecurity is not required when the subscription is created by a
member of the sysadmin fixed server role, however it is recommended. In this case, the agent will
impersonate the SQL Server Agent account. For more information, see Replication Agent Security Model.
(Optional) A value of true for CreateSyncAgentByDefault to create an agent job that is used to
synchronize the subscription. If you specify false (the default), the subscription can only be
synchronized programmatically and you must specify additional properties of
TransSynchronizationAgent when you access this object from the SynchronizationAgent property.
For more information, see Synchronize a Pull Subscription.
NOTE
SQL Server Agent is not available in every edition of Microsoft SQL Server. For a list of features that are
supported by the editions of SQL Server, see Features Supported by the Editions of SQL Server 2016.
When you specify a value of true for Express Subscribers, the agent job is not created. However,
important subscription-related metadata is stored at the Subscriber.
(Optional) Set the SqlStandardLogin and SqlStandardPassword or SecureSqlStandardPassword

fields of DistributorSecurity when using SQL Server Authentication to connect to the Distributor.
9. Using the instance of the TransPublication class from step 2, call the MakePullSubscriptionWellKnown
method to register the pull subscription with the Publisher. If this registration already exists, an exception
occurs.
To create a pull subscription to a merge publication
1. Create connections to both the Subscriber and Publisher by using the ServerConnection class.
2. Create an instance of the MergePublication class by using the Publisher connection from step 1. Specify
Name, DatabaseName, and ConnectionContext.
and AllowPull. If the result is None, set Attributes to the result of a bitwise logical OR (| in Visual C# and
Or in Visual Basic) between Attributes and AllowPull. Then, call CommitPropertyChanges to enable pull
subscriptions.
6. Create an instance of the MergePullSubscription class.
The ServerConnection to the Subscriber created in step 1 for ConnectionContext.
Name of the subscription database for DatabaseName.
Name of the Publisher for PublisherName.
Name of the publication database for PublicationDBName.
for the Microsoft Windows account under which the Merge Agent runs at the Subscriber. This
account is used to make local connections to the Subscriber and to make remote connections
NOTE
Setting SynchronizationAgentProcessSecurity is not required when the subscription is created by a
member of the sysadmin fixed server role, however it is recommended. In this case, the agent will
impersonate the SQL Server Agent account. For more information, see Replication Agent Security Model.
(Optional) A value of true for CreateSyncAgentByDefault to create an agent job that is used to
synchronize the subscription. If you specify false (the default), the subscription can only be
synchronized programmatically and you must specify additional properties of
MergeSynchronizationAgent when you access this object from the SynchronizationAgent
property. For more information, see Synchronize a Pull Subscription.
fields of DistributorSecurity when using SQL Server Authentication to connect to the Distributor.
fields of PublisherSecurity when using SQL Server Authentication to connect to the Publisher.
9. Using the instance of the MergePublication class from step 2, call the MakePullSubscriptionWellKnown
method to register the pull subscription with the Publisher. If this registration already exists, an exception
occurs.
Example (RMO )
This example creates a pull subscription to a transactional publication. The Microsoft Windows account
credentials used to create the Distribution Agent job are passed at runtime.
// Define the Publisher, publication, and databases.

string publicationName = "AdvWorksProductTran";
string subscriberName = subscriberInstance;
string subscriptionDbName = "AdventureWorksReplica";
string publicationDbName = "AdventureWorks";
//Create connections to the Publisher and Subscriber.

ServerConnection subscriberConn = new ServerConnection(subscriberName);
// Create the objects that we need.

TransPublication publication;
TransPullSubscription subscription;
try
{
// Connect to the Publisher and Subscriber.
subscriberConn.Connect();
// Ensure that the publication exists and that

// it supports pull subscriptions.
publication = new TransPublication();
publication.Name = publicationName;
publication.DatabaseName = publicationDbName;
publication.ConnectionContext = publisherConn;
if (publication.IsExistingObject)
{
if ((publication.Attributes & PublicationAttributes.AllowPull) == 0)
{
publication.Attributes |= PublicationAttributes.AllowPull;
}
// Define the pull subscription.

subscription = new TransPullSubscription();
subscription.ConnectionContext = subscriberConn;
subscription.PublisherName = publisherName;
subscription.PublicationName = publicationName;
subscription.PublicationDBName = publicationDbName;
subscription.DatabaseName = subscriptionDbName;
// Specify the Windows login credentials for the Distribution Agent job.
subscription.SynchronizationAgentProcessSecurity.Login = winLogin;
subscription.SynchronizationAgentProcessSecurity.Password = winPassword;
// Make sure that the agent job for the subscription is created.
subscription.CreateSyncAgentByDefault = true;
// By default, subscriptions to transactional publications are synchronized

// continuously, but in this case we only want to synchronize on demand.
subscription.AgentSchedule.FrequencyType = ScheduleFrequencyType.OnDemand;
// Create the pull subscription at the Subscriber.

subscription.Create();
Boolean registered = false;
// Verify that the subscription is not already registered.

foreach (TransSubscription existing
in publication.EnumSubscriptions())
{
if (existing.SubscriberName == subscriberName
&& existing.SubscriptionDBName == subscriptionDbName)
{
registered = true;
}
}
if (!registered)
{
// Register the subscription with the Publisher.
publication.MakePullSubscriptionWellKnown(
subscriberName, subscriptionDbName,
SubscriptionSyncType.Automatic,
TransSubscriberType.ReadOnly);
}
}
else
{
// Do something here if the publication does not exist.
"The publication '{0}' does not exist on {1}.",
publicationName, publisherName));
}
}
{
"The subscription to {0} could not be created.", publicationName), ex);
}
finally
{
subscriberConn.Disconnect();
}
' Define the Publisher, publication, and databases.

Dim publicationName As String = "AdvWorksProductTran"
Dim subscriberName As String = subscriberInstance
Dim subscriptionDbName As String = "AdventureWorksReplica"
Dim publicationDbName As String = "AdventureWorks"
'Create connections to the Publisher and Subscriber.

Dim subscriberConn As ServerConnection = New ServerConnection(subscriberName)
' Create the objects that we need.

Dim publication As TransPublication
Dim subscription As TransPullSubscription
Try
' Connect to the Publisher and Subscriber.
subscriberConn.Connect()
' Ensure that the publication exists and that

' it supports pull subscriptions.
publication = New TransPublication()
publication.Name = publicationName
publication.DatabaseName = publicationDbName
publication.ConnectionContext = publisherConn
If publication.IsExistingObject Then
If (publication.Attributes And PublicationAttributes.AllowPull) = 0 Then
publication.Attributes = publication.Attributes _
Or PublicationAttributes.AllowPull
End If
' Define the pull subscription.
subscription = New TransPullSubscription()
subscription.ConnectionContext = subscriberConn
subscription.PublisherName = publisherName
subscription.PublicationName = publicationName
subscription.PublicationDBName = publicationDbName
subscription.DatabaseName = subscriptionDbName
subscription.Description = "Pull subscription to " + publicationDbName _
+ " on " + subscriberName + "."
' Specify the Windows login credentials for the Distribution Agent job.
subscription.SynchronizationAgentProcessSecurity.Login = winLogin
subscription.SynchronizationAgentProcessSecurity.Password = winPassword
' Make sure that the agent job for the subscription is created.
subscription.CreateSyncAgentByDefault = True
' By default, subscriptions to transactional publications are synchronized

' continuously, but in this case we only want to synchronize on demand.
subscription.AgentSchedule.FrequencyType = ScheduleFrequencyType.OnDemand
' Create the pull subscription at the Subscriber.

subscription.Create()
Dim registered As Boolean = False
' Verify that the subscription is not already registered.

For Each existing As TransSubscription In publication.EnumSubscriptions()
If existing.SubscriberName = subscriberName And _
existing.SubscriptionDBName = subscriptionDbName Then
registered = True
End If
Next existing
If Not registered Then
' Register the subscription with the Publisher.
publication.MakePullSubscriptionWellKnown( _
subscriberName, subscriptionDbName, _
SubscriptionSyncType.Automatic, _
TransSubscriberType.ReadOnly)
End If
Else
' Do something here if the publication does not exist.
"The publication '{0}' does not exist on {1}.", _
publicationName, publisherName))
End If
"The subscription to {0} could not be created.", publicationName), ex)
Finally
subscriberConn.Disconnect()
End Try
This example creates a pull subscription to a merge publication. The Windows account credentials used to
create the Merge Agent job are passed at runtime.

string publicationName = "AdvWorksSalesOrdersMerge";
string hostname = @"adventure-works\garrett1";

MergePublication publication;
MergePullSubscription subscription;
try
{
// Connect to the Subscriber.

publication = new MergePublication();
if (publication.LoadProperties())
{
{
}

subscription = new MergePullSubscription();
subscription.HostName = hostname;
// Specify the Windows login credentials for the Merge Agent job.
// Make sure that the agent job for the subscription is created.


foreach (MergeSubscription existing
{
&& existing.SubscriptionDBName == subscriptionDbName
&& existing.SubscriptionType == SubscriptionOption.Pull)
{
registered = true;
}
}
if (!registered)
{
// Register the local subscription with the Publisher.
MergeSubscriberType.Local, 0);
}
}
else
else
{
}
}
{
}
finally
{
}

Dim publicationName As String = "AdvWorksSalesOrdersMerge"
Dim hostname As String = "adventure-works\garrett1"


Dim publication As MergePublication
Dim subscription As MergePullSubscription
Try
' Connect to the Subscriber.

publication = New MergePublication()
If publication.LoadProperties() Then
End If

subscription = New MergePullSubscription()
subscription.HostName = hostname
' Specify the Windows login credentials for the Merge Agent job.
' Make sure that the agent job for the subscription is created.


For Each existing As MergeSubscription In _
publication.EnumSubscriptions()
If existing.SubscriberName = subscriberName Then
registered = True
End If
Next
' Register the local subscription with the Publisher.
MergeSubscriberType.Local, 0)
End If
Else
End If
Finally
End Try
This example creates a pull subscription to a merge publication without creating an associated agent job and
subscription metadata in MSsubscription_properties. The Windows account credentials used to create the
Merge Agent job are passed at runtime.



try
{

{
{
}

// Specify that an agent job not be created for this subscription. The
// subscription can only be synchronized by running the Merge Agent directly.
// Subscripition metadata stored in MSsubscription_properties will not
// be available and must be specified at run time.
subscription.CreateSyncAgentByDefault = false;


{
{
registered = true;
}
}
if (!registered)
{
}
}
else
{
}
}
{
}
finally
{
}



Try

End If

' Specify that an agent job not be created for this subscription. The
' subscription can only be synchronized by running the Merge Agent directly.
' Subscripition metadata stored in MSsubscription_properties will not
' be available and must be specified at run time.
subscription.CreateSyncAgentByDefault = False


registered = True
End If
Next
End If
Else
End If
Finally
End Try
This example creates a pull subscription to a merge publication that can be synchronized over the Internet
using Web synchronization. The Windows account credentials used to create the Merge Agent job are passed at
runtime. For more information, see Configure Web Synchronization.

string webSyncUrl = "https://" + publisherInstance + "/WebSync/replisapi.dll";


try
{

// it supports pull subscriptions and Web synchronization.
{
{
}
if ((publication.Attributes & PublicationAttributes.AllowWebSynchronization) == 0)
{
publication.Attributes |= PublicationAttributes.AllowWebSynchronization;
}

// Enable Web synchronization.
subscription.UseWebSynchronization = true;
subscription.InternetUrl = webSyncUrl;
// Specify the same Windows credentials to use when connecting to the

// Web server using HTTPS Basic Authentication.
subscription.InternetSecurityMode = AuthenticationMethod.BasicAuthentication;
subscription.InternetLogin = winLogin;
subscription.InternetPassword = winPassword;
// Ensure that we create a job for this subscription.



{
{
registered = true;
}
}
if (!registered)
{
}
}
else
{
}
}
{
}
finally
{
}

Dim webSyncUrl As String = "https://" + publisherInstance + "/WebSync/replisapi.dll"

Try

' it supports pull subscriptions and Web synchronization.
End If
If (publication.Attributes And PublicationAttributes.AllowWebSynchronization) = 0 Then
Or PublicationAttributes.AllowWebSynchronization
End If

' Enable Web synchronization.

subscription.UseWebSynchronization = True
subscription.InternetUrl = webSyncUrl
' Specify the same Windows credentials to use when connecting to the
' Web server using HTTPS Basic Authentication.
subscription.InternetSecurityMode = AuthenticationMethod.BasicAuthentication
subscription.InternetLogin = winLogin
subscription.InternetPassword = winPassword


registered = True
End If
Next
End If
Else
End If
Finally
End Try
See Also
Replication Security Best Practices
Data Warehouse
This topic describes how to create a push subscription in SQL Server 2017 by using SQL Server Management
Studio, Transact-SQL, or Replication Management Objects (RMO). For information about creating a push
subscription for a non- SQL Server Subscriber, see Create a Subscription for a Non-SQL Server Subscriber.

Create a push subscription at the Publisher or the Subscriber using the New Subscription Wizard. Follow the
pages in the wizard to:
Specify the Publisher and publication.
Select where replication agents will run. For a push subscription, select Run all agents at the
Distributor (push subscriptions) on the Distribution Agent Location page or Merge Agent
Location page, depending on the type of publication.
Specify Subscribers and subscription databases.
Specify the logins and passwords used for connections made by replication agents:
For subscriptions to snapshot and transactional publications, specify credentials on the
Distribution Agent Security page.
For subscriptions to merge publications, specify credentials on the Merge Agent Security page.
For information about the permissions required by each agent, see Replication Agent Security
Model.
Specify a synchronization schedule and when the Subscriber should be initialized.
Specify additional options for merge publications: subscription type; and values for parameterized
filtering.
Specify additional options for transactional publications that allow updating subscriptions: whether
Subscribers should commit changes at the Publisher immediately or write them to a queue; credentials
used to connect from the Subscriber to the Publisher.
Optionally script the subscription.
To create a push subscription from the Publisher
1. Connect to the Publisher in Microsoft SQL Server Management Studio, and then expand the server node.
3. Right-click the publication for which you want to create one or more subscriptions, and then click New
Subscriptions.
To create a push subscription from the Subscriber
2. Expand the Replication folder.
3. Right-click the Local Subscriptions folder, and then click New Subscriptions.
4. On the Publication page of the New Subscription Wizard, select <Find SQL Server Publisher> or
<Find Oracle Publisher> from the Publisher drop-down list.
5. Connect to the Publisher in the Connect to Server dialog box.
6. Select a publication on the Publication page.
Using Transact-SQL
Push subscriptions can be created programmatically using replication stored procedures. The stored
procedures used will depend on the type of publication to which the subscription belongs.
IMPORTANT! When possible, prompt users to enter security credentials at run time. If you must store
credentials in a script file, you must secure the file to prevent unauthorized access.
To create a push subscription to a snapshot or transactional publication

1. At the Publisher on the publication database, verify that the publication supports push subscriptions by
executing sp_helppublication.
If the value of allow_push is 1, push subscriptions are supported.
If the value of allow_push is 0, execute sp_changepublication, specifying allow_push for
@property and true for @value.
2. At the Publisher on the publication database, execute sp_addsubscription. Specify @publication,
@subscriber and @destination_db. Specify a value of push for @subscription_type. For information
about how to update subscriptions, see Create an Updatable Subscription to a Transactional Publication.
3. At the Publisher on the publication database, execute sp_addpushsubscription_agent. Specify the
following:
The @subscriber, @subscriber_db, and @publication parameters.
The Microsoft Windows credentials under which the Distribution Agent at the Distributor runs for
NOTE: Connections made using Windows Integrated Authentication always use the Windows
credentials specified by @job_login and @job_password. The Distribution Agent always
makes the local connection to the Distributor using Windows Integrated Authentication. By
default, the agent will connect to the Subscriber using Windows Integrated Authentication.
(Optional) A value of 0 for @subscriber_security_mode and the Microsoft SQL Server login
information for @subscriber_login and @subscriber_password. Specify these parameters if
you need to use SQL Server Authentication when connecting to the Subscriber.
IMPORTANT!! When creating a push subscription at a Publisher with a remote Distributor, the
values supplied for all parameters, including job_login and job_password, are sent to the Distributor
as plain text. You should encrypt the connection between the Publisher and its remote Distributor
before executing this stored procedure. For more information, see Enable Encrypted Connections to
the Database Engine (SQL Server Configuration Manager).
To create a push subscription to a merge publication

1. At the Publisher on the publication database, verify that the publication supports push subscriptions by
executing sp_helpmergepublication.
If the value of allow_push is 1, the publication supports push subscriptions.
If the value of allow_push is not 1, execute sp_changemergepublication, specifying allow_push
for @property and true for @value.
2. At the Publisher on the publication database, execute sp_addmergesubscription, specifying the following
parameters:
@publication. This is the name of the publication.
@subscriber_type. For a client subscription, specify local and for a server subscription, specify
global.
@subscription_priority. For a server subscription, specify a priority for the subscription (0.00 to
99.99).
For more information, see Advanced Merge Replication Conflict Detection and Resolution.
3. At the Publisher on the publication database, execute sp_addmergepushsubscription_agent. Specify the
following:
The @subscriber, @subscriber_db, and @publication parameters.
The Windows credentials under which the Merge Agent at the Distributor runs for @job_login
and @job_password.
NOTE: Connections made using Windows Integrated Authentication always use the Windows
credentials specified by @job_login and @job_password. The Merge Agent always makes
the local connection to the Distributor using Windows Integrated Authentication. By default,
the agent will connect to the Subscriber using Windows Integrated Authentication.
(Optional) A value of 0 for @subscriber_security_mode and the SQL Server login information
for @subscriber_login and @subscriber_password. Specify these parameters if you need to
use SQL Server Authentication when connecting to the Subscriber.
(Optional) A value of 0 for @publisher_security_mode and the SQL Server login information for
@publisher_login and @publisher_password. Specify these values if you need to use SQL
Server Authentication when connecting to the Publisher.
A schedule for the Merge Agent job for this subscription. For more information, see Specify
IMPORTANT!! When creating a push subscription at a Publisher with a remote Distributor, the
values supplied for all parameters, including job_login and job_password, are sent to the Distributor
as plain text. You should encrypt the connection between the Publisher and its remote Distributor
before executing this stored procedure. For more information, see Enable Encrypted Connections to
the Database Engine (SQL Server Configuration Manager).
The following example creates a push subscription to a transactional publication. Login and password values
are supplied at run time by using sqlcmd scripting variables.

SET @subscriptionDB = N'AdventureWorks2012Replica';
--Add a push subscription to a transactional publication.

EXEC sp_addsubscription
@destination_db = @subscriptionDB,
@subscription_type = N'push';
--Add an agent job to synchronize the push subscription.

EXEC sp_addpushsubscription_agent
@subscriber_db = @subscriptionDB,
GO
The following example creates a push subscription to a merge publication. Login and password values are
supplied at run time by using sqlcmd scripting variables.

DECLARE @hostname AS sysname;
SET @subscriptionDB = N'AdventureWorksReplica';
SET @hostname = N'adventure-works\david8'
-- Add a push subscription to a merge publication.

USE [AdventureWorks2012];
EXEC sp_addmergesubscription
@subscription_type = N'push',
@hostname = @hostname;
--Add an agent job to synchronize the push subscription.

EXEC sp_addmergepushsubscription_agent
GO

You can create push subscriptions programmatically by using Replication Management Objects (RMO). The
RMO classes you use to create a push subscription depend on the type of publication to which the subscription
is created.
IMPORTANT! When possible, prompt users to enter security credentials at runtime. If you must store
credentials, use the cryptographic services provided by the Microsoft Windows .NET Framework.
To create a push subscription to a snapshot or transactional publication

incorrect or the publication does not exists on the server.
and AllowPush. If the result is None, set Attributes to the result of a bitwise logical OR (| in Visual C# and
Or in Visual Basic) between Attributes and AllowPush. Then, call CommitPropertyChanges to enable push
subscriptions.
6. Create an instance of the TransSubscription class.
The ServerConnection to the Publisher created in step 1 for ConnectionContext.
Name of the subscription database for SubscriptionDBName.
Name of the Subscriber for SubscriberName.
Name of the publication database for DatabaseName.
for the Microsoft Windows account under which the Distribution Agent runs at the Distributor.
This account is used to make local connections to the Distributor and to make remote connections
NOTE: Setting SynchronizationAgentProcessSecurity is not required when the subscription is

created by a member of the sysadmin fixed server role, however it is recommended. In this
case, the agent will impersonate the SQL Server Agent account. For more information, see
Replication Agent Security Model.
(Optional) A value of true (the default) for CreateSyncAgentByDefault to create an agent job that
is used to synchronize the subscription. If you specify false, the subscription can only be
synchronized programmatically.
fields of SubscriberSecurity when using SQL Server Authentication to connect to the Subscriber.
IMPORTANT!!When creating a push subscription at a Publisher with a remote Distributor, the

values supplied for all properties, including SynchronizationAgentProcessSecurity, are sent to the
Distributor as plain text. You should encrypt the connection between the Publisher and its remote
Distributor before calling the Create method. For more information, see Enable Encrypted
Connections to the Database Engine (SQL Server Configuration Manager).
To create a push subscription to a merge publication

incorrect or the publication does not exists on the server.
and AllowPush. If the result is None, set Attributes to the result of a bitwise logical OR (| in Visual C# and
Or in Visual Basic) between Attributes and AllowPush. Then, call CommitPropertyChanges to enable push
subscriptions.
6. Create an instance of the MergeSubscription class.
The ServerConnection to the Publisher created in step 1 for ConnectionContext.
Name of the subscription database for SubscriptionDBName.
Name of the Subscriber for SubscriberName.
Name of the publication database for DatabaseName.
for the Microsoft Windows account under which the Merge Agent runs at the Distributor. This
account is used to make local connections to the Distributor and to make remote connections
NOTE: Setting SynchronizationAgentProcessSecurity is not required when the subscription is

created by a member of the sysadmin fixed server role, however it is recommended. In this
case, the agent will impersonate the SQL Server Agent account. For more information, see
(Optional) A value of true (the default) for CreateSyncAgentByDefault to create an agent job that
is used to synchronize the subscription. If you specify false, the subscription can only be
synchronized programmatically.
fields of SubscriberSecurity when using SQL Server Authentication to connect to the Subscriber.
fields of PublisherSecurity when using SQL Server Authentication to connect to the Publisher.
IMPORTANT! When creating a push subscription at a Publisher with a remote Distributor, the values
supplied for all properties, including SynchronizationAgentProcessSecurity, are sent to the
Distributor as plain text. You should encrypt the connection between the Publisher and its remote
Distributor before calling the Create method. For more information, see Enable Encrypted
Connections to the Database Engine (SQL Server Configuration Manager).
Examples (RMO )
This example creates a new push subscription to a transactional publication. The Windows account credentials
you use to run the Distribution Agent job are passed at runtime.

string subscriptionDbName = "AdventureWorks2012Replica";
//Create a connection to the Publisher.

ServerConnection conn = new ServerConnection(subscriberName);

TransSubscription subscription;
try
{
// Connect to the Publisher.
conn.Connect();
// it supports push subscriptions.
publication.ConnectionContext = conn;
{
if ((publication.Attributes & PublicationAttributes.AllowPush) == 0)
{
publication.Attributes |= PublicationAttributes.AllowPush;
}
// Define the push subscription.

subscription = new TransSubscription();
subscription.ConnectionContext = conn;
subscription.SubscriberName = subscriberName;
subscription.DatabaseName = publicationDbName;
subscription.SubscriptionDBName = subscriptionDbName;
// Specify the Windows login credentials for the Distribution Agent job.
// By default, subscriptions to transactional publications are synchronized

// continuously, but in this case we only want to synchronize on demand.
subscription.AgentSchedule.FrequencyType = ScheduleFrequencyType.OnDemand;
// Create the push subscription.

}
else
{
}
}
{
}
finally
{
conn.Disconnect();
}
Dim subscriptionDbName As String = "AdventureWorks2012Replica"
'Create a connection to the Publisher.

Dim conn As ServerConnection = New ServerConnection(subscriberName)

Dim subscription As TransSubscription
Try
' Connect to the Publisher.
conn.Connect()

' it supports push subscriptions.
publication.ConnectionContext = conn
If (publication.Attributes And PublicationAttributes.AllowPush) = 0 Then
Or PublicationAttributes.AllowPush
End If
' Define the push subscription.

subscription = New TransSubscription()
subscription.ConnectionContext = conn
subscription.SubscriberName = subscriberName
subscription.DatabaseName = publicationDbName
subscription.SubscriptionDBName = subscriptionDbName
' Specify the Windows login credentials for the Distribution Agent job.
' By default, subscriptions to transactional publications are synchronized

' continuously, but in this case we only want to synchronize on demand.
subscription.AgentSchedule.FrequencyType = ScheduleFrequencyType.OnDemand
' Create the push subscription.

Else
End If
Finally
conn.Disconnect()
End Try
This example creates a new push subscription to a merge publication. The Windows account credentials you use
to run the Merge Agent job are passed at runtime.


MergeSubscription subscription;
try
{
conn.Connect();

{
{
}

subscription = new MergeSubscription();
// Set a schedule to synchronize the subscription every 2 hours

// during weekdays from 6am to 10pm.
subscription.AgentSchedule.FrequencyType = ScheduleFrequencyType.Weekly;
subscription.AgentSchedule.FrequencyInterval = Convert.ToInt32(0x003E);
subscription.AgentSchedule.FrequencyRecurrenceFactor = 1;
subscription.AgentSchedule.FrequencySubDay = ScheduleFrequencySubDay.Hour;
subscription.AgentSchedule.FrequencySubDayInterval = 2;
subscription.AgentSchedule.ActiveStartDate = 20051108;
subscription.AgentSchedule.ActiveEndDate = 20071231;
subscription.AgentSchedule.ActiveStartTime = 060000;
subscription.AgentSchedule.ActiveEndTime = 100000;

}
else
{
}
}
{
}
finally
{
conn.Disconnect();
}



Dim subscription As MergeSubscription
Try
conn.Connect()

End If

subscription = New MergeSubscription()
' Set a schedule to synchronize the subscription every 2 hours

' during weekdays from 6am to 10pm.
subscription.AgentSchedule.FrequencyType = ScheduleFrequencyType.Weekly
subscription.AgentSchedule.FrequencyInterval = Convert.ToInt32("0x003E", 16)
subscription.AgentSchedule.FrequencyRecurrenceFactor = 1
subscription.AgentSchedule.FrequencySubDay = ScheduleFrequencySubDay.Hour
subscription.AgentSchedule.FrequencySubDayInterval = 2
subscription.AgentSchedule.ActiveStartDate = 20051108
subscription.AgentSchedule.ActiveEndDate = 20071231
subscription.AgentSchedule.ActiveStartTime = 60000
subscription.AgentSchedule.ActiveEndTime = 100000

Else

End If
Finally
conn.Disconnect()
End Try
See Also
Use sqlcmd with Scripting Variables
Warehouse
This topic describes how to view and modify pull subscription properties in SQL Server 2017 by using SQL
Server Management Studio, Transact-SQL, or Replication Management Objects (RMO).
In This Topic
To view and modify pull subscription properties, using:
Transact-SQL

View pull subscription properties from the Publisher or the Subscriber in the Subscription Properties -
<Publisher>: <PublicationDatabase> dialog box, which is available from SQL Server Management Studio.
More properties are visible from the Subscriber, and properties can be modified at the Subscriber. You can also
view properties from the Publisher on the All Subscriptions tab, which is available in Replication Monitor. For
information about starting Replication Monitor, see Start the Replication Monitor.
To view pull subscription properties from the Publisher in Management Studio
1. Connect to the Publisher in Management Studio, and then expand the server node.
3. Expand the appropriate publication, right-click a subscription, and then click Properties.
4. View properties, and then click OK.
To view and modify pull subscription properties from the Subscriber in Management Studio
1. Connect to the Subscriber in Management Studio, and then expand the server node.
2. Expand the Replication folder, and then expand the Local Subscriptions folder.
3. Right-click a subscription, and then click Properties.
To view pull subscription properties from the Publisher in Replication Monitor
1. Expand a Publisher group in the left pane of Replication Monitor, expand a Publisher, and then click a
publication.
2. Click the All Subscriptions tab.
4. View properties, and then click OK.
Using Transact-SQL
Pull subscriptions can be modified and their properties accessed programmatically using replication stored
procedures. The stored procedures used depend on the type of publication to which the subscription belongs.
To view the properties of a pull subscription to a snapshot or transactional publication
1. At the Subscriber, execute sp_helppullsubscription. Specify @publisher, @publisher_db, and
@publication. This returns information about the subscription that is stored in system tables at the
Subscriber.
2. At the Subscriber, execute sp_helpsubscription_properties. Specify @publisher, @publisher_db,
@publication, and one of the following values for @publication_type:
0 - Subscription belongs to a transactional publication.
1 - Subscription belongs to a snapshot publication.
3. At the Publisher, execute sp_helpsubscription. Specify @publication and @subscriber.
4. At the Publisher, execute sp_helpsubscriberinfo, specifying @subscriber. This displays information about
the Subscriber.
To change the properties of a pull subscription to a snapshot or transactional publication
1. At the Subscriber, execute sp_change_subscription_properties, specifying @publisher, @publisher_db,
@publication, a value of either 0 (transactional) or 1 (snapshot) for @publication_type, the subscription
property being changed as @property, and the new value as @value.
2. (Optional) At the Subscriber on the subscription database, execute sp_changesubscriptiondtsinfo. Specify
the ID of the Distribution Agent job for @jobid, and the following Data Transformation Services (DTS)
package properties:
@dts_package_name
@dts_package_password
@dts_package_location
This changes the DTS package properties of a subscription.
NOTE
The job ID can be obtained by executing sp_helpsubscription.
To view the properties of a pull subscription to a merge publication

1. At the Subscriber, execute sp_helpmergepullsubscription. Specify @publisher, @publisher_db, and
@publication.
2. At the Subscriber, execute sp_helpsubscription_properties. Specify @publisher, @publisher_db,
@publication, and a value of 2 for @publication_type.
3. At the Publisher, execute sp_helpmergesubscription to display subscription information. To return
information on a specific subscription, you must specify @publication, @subscriber, and a value of pull
for @subscription_type.
4. At the Publisher, execute sp_helpsubscriberinfo, specifying @subscriber. This displays information about
the Subscriber.
To change the properties of a pull subscription to a merge publication
1. At the Subscriber, execute sp_changemergepullsubscription. Specify @publication, @publisher,
@publisher_db, the subscription property being changed as @property, and the new value as @value.
The RMO classes you use to view or modify pull subscription properties depend on the type of publication to
which the pull subscription is subscribed.
To view or modify properties of a pull subscription to a snapshot or transactional publication
1. Create a connection to the Subscriber by using the ServerConnection class.
2. Create an instance of the TransPullSubscription class.
3. Set the PublicationName, DatabaseName, PublisherName, and PublicationDBName properties.
4. Set the connection from step 1 for the ConnectionContext property.
5. Call the LoadProperties method to get the properties of the object. If this method returns false, either the
subscription properties in step 3 were defined incorrectly or the subscription does not exist on the server.
6. (Optional) To change properties, set a new value for one of the TransPullSubscription properties that can
be set, and then call the CommitPropertyChanges method.
7. (Optional) To view the new settings, call the Refresh method to reload the properties for the article.
8. Close all connections.
To view or modify properties of a pull subscription to a merge publication
2. Create an instance of the MergePullSubscription class.
3. Set the PublicationName, DatabaseName, PublisherName, and PublicationDBName properties.
subscription properties in step 3 were defined incorrectly or the subscription does not exist on the server.
6. (Optional) To change properties, set a new value for one of the MergePullSubscription properties that can
be set, and then call the CommitPropertyChanges method.
7. (Optional) To view the new settings, call the Refresh method to reload the properties for the article.
8. Close all connections.
See Also
View Information and Perform Tasks for a Subscription (Replication Monitor)
Warehouse
This topic describes how to view and modify push subscription properties in SQL Server 2017 by using SQL
Server Management Studio, Transact-SQL, or Replication Management Objects (RMO).
In This Topic
To view and modify push subscription properties, using:
Transact-SQL

View and modify push subscription properties from the Publisher in:
The Subscription Properties - <Publisher>: <PublicationDatabase> dialog box, which is available
from SQL Server Management Studio.
The All Subscriptions tab, which is available in Replication Monitor. For information about starting
Replication Monitor, see Start the Replication Monitor.
To view and modify push subscription properties in Management Studio
3. Expand the appropriate publication, right-click a subscription, and then click Properties.
To view and modify push subscription properties in Replication Monitor
publication.
Using Transact-SQL
Push subscriptions can be modified and their properties accessed programmatically using replication stored
procedures. The stored procedures used depend on the type of publication to which the subscription belongs.
To view the properties of a push subscription to a snapshot or transactional publication
1. At the Publisher on the publication database, execute sp_helpsubscription. Specify @publication,
@subscriber, and a value of all for @article.
2. At the Publisher on the publication database, execute sp_helpsubscriberinfo, specifying @subscriber.
To change the properties of a push subscription to a snapshot or transactional publication
1. At the Publisher on the publication database, execute sp_changesubscriber, specifying @subscriber and
any parameters for the Subscriber properties being changed.
2. At the Publisher on the publication database, execute sp_changesubscription. Specify @publication,
@subscriber, @destination_db, a value of all for @article, the subscription property being changed as
@property, and the new value as @value. This changes security settings for the push subscription.
3. (Optional) To change the Data Transformation Services (DTS) package properties of a subscription, execute
sp_changesubscriptiondtsinfo at the Subscriber on the subscription database. Specify the ID of the
Distribution Agent job for @jobid and the following DTS package properties:
@dts_package_name
@dts_package_password
@dts_package_location
This changes the DTS package properties of a subscription.
NOTE
The job ID can be obtained by executing sp_helpsubscription.
To view the properties of a push subscription to a merge publication

1. At the Publisher on the publication database, execute sp_helpmergesubscription. Specify @publication
and @subscriber.
2. At the Publisher, execute sp_helpsubscriberinfo, specifying @subscriber.
To change the properties of a push subscription to a merge publication
1. At the Publisher on the publication database, execute sp_changemergesubscription. Specify @publication,
@subscriber, @subscriber_db, the subscription property being changed as @property, and the new value
as @value.
Example (Transact-SQL )

The RMO classes you use to view or modify push subscription properties depend on the type of publication to
which the push subscription is subscribed.
To view or modify properties of a push subscription to a snapshot or transactional publication
3. Set the PublicationName, DatabaseName, SubscriberName, and SubscriptionDBName properties.
4. Set the ServerConnection from step 1 for the ConnectionContext property setting.
subscription properties in step 3 were defined incorrectly or the subscription does not exist.
6. (Optional) To change properties, set a new value for one of the TransSubscription properties that can be
set, and then call the CommitPropertyChanges method.
7. (Optional) To view the new settings, call the Refresh method to reload the properties for the subscription.
To view or modify properties of a push subscription to a merge publication
3. Set the PublicationName, DatabaseName, SubscriberName, and SubscriptionDBName properties.
4. Set the ServerConnection from step 1 for the ConnectionContext property setting.
subscription properties in step 3 were defined incorrectly or the subscription does not exist.
6. (Optional) To change properties, set a new value for one of the MergeSubscription properties that can be
set, and then call the CommitPropertyChanges method.
7. (Optional) To view the new settings, call the Refresh method to reload the properties for the subscription.
See Also
Warehouse
This topic describes how to delete a pull subscription in SQL Server 2017 by using SQL Server Management
In This Topic
To delete a pull subscription, using:
Transact-SQL

Delete a pull subscription at the Publisher (from the Local Publications folder in SQL Server Management
Studio) or the Subscriber (from the Local Subscriptions folder). Deleting a subscription does not remove objects
or data from the subscription; they must be removed manually.
To delete a pull subscription at the Publisher
3. Expand the publication associated with the subscription you want to delete.
4. Right-click the subscription, and then click Delete.
5. In the confirmation dialog box, select whether to connect to the Subscriber to delete subscription
information. If you clear the Connect to Subscriber check box, you should connect to the Subscriber later
to delete the information.
To delete a pull subscription at the Subscriber
3. Right-click the subscription you want to delete, and then click Delete.
4. In the confirmation dialog box, select whether to connect to the Publisher to delete subscription
information. If you clear the Connect to Publisher check box, you should connect to the Publisher later to
delete the information.
Using Transact-SQL
Pull subscriptions can be deleted programmatically using replication stored procedures. The stored procedures
used will depend on the type of publication to which the subscription belongs.
To delete a pull subscription to a snapshot or transactional publication
1. At the Subscriber on the subscription database, execute sp_droppullsubscription (Transact-SQL). Specify
@publication, @publisher, and @publisher_db.
2. At the Publisher on the publication database, execute sp_dropsubscription (Transact-SQL). Specify
@publication and @subscriber. Specify a value of all for @article. (Optional) If the Distributor cannot be
accessed, specify a value of 1 for @ignore_distributor to delete the subscription without removing related
objects at the Distributor.
To delete a pull subscription to a merge publication
1. At the Subscriber on the subscription database, execute sp_dropmergepullsubscription (Transact-SQL).
Specify @publication, @publisher, and @publisher_db.
2. At the Publisher on the publication database, execute sp_dropmergesubscription (Transact-SQL). Specify
@publication, @subscriber, and @subscriber_db. Specify a value of pull for @subscription_type.
(Optional) If the Distributor cannot be accessed, specify a value of 1 for @ignore_distributor to delete the
subscription without removing related objects at the Distributor.
The following example deletes a pull subscription to a transactional publication. The first batch is executed at the
Subscriber and the second is executed at the Publisher.
-- This is the batch executed at the Subscriber to drop

-- a pull subscription to a transactional publication.
USE [AdventureWorks2012Replica]
EXEC sp_droppullsubscription
@publication = @publication;
GO
-- This batch is executed at the Publisher to remove

-- a pull or push subscription to a transactional publication.
EXEC sp_dropsubscription
@article = N'all',
@subscriber = @subscriber;
GO
The following example deletes a pull subscription to a merge publication. The first batch is executed at the
Subscriber and the second is executed at the Publisher.
-- This batch is executed at the Subscriber to remove

-- a merge pull subscription.
DECLARE @publication_db AS sysname;
SET @publication_db = N'AdventureWorks2012';
USE [AdventureWorks2012Replica]
EXEC sp_dropmergepullsubscription
@publisher_db = @publication_db,
GO

-- a pull or push subscription to a merge publication.
EXEC sp_dropmergesubscription
@subscriber_db = @subscriptionDB;
GO

You can delete pull subscriptions programmatically by using Replication Management Objects (RMO). The RMO
classes that you use to delete a pull subscription depend on the type of publication to which the pull subscription
is subscribed.
To delete a pull subscription to a snapshot or transactional publication
2. Create an instance of the TransPullSubscription class, and set the PublicationName, DatabaseName,
PublisherName, and PublicationDBName properties. Use the Subscriber connection from step 1 to set the
ConnectionContext property.
3. Check the IsExistingObject property to verify that the subscription exists. If the value of this property is
false, either the subscription properties in step 2 were defined incorrectly or the subscription does not exist.
4. Call the Remove method.
7. Call the RemovePullSubscription method. Specify the name of the Subscriber and the subscription database
for the subscriber and subscriberDB parameters.
To delete a pull subscription to a merge publication
2. Create an instance of the MergePullSubscription class, and set the PublicationName, DatabaseName,
PublisherName, and PublicationDBName properties. Use the connection from step 1 to set the
ConnectionContext property.
7. Call the RemovePullSubscription method. Specify the name of the Subscriber and the subscription database
for the subscriber and subscriberDB parameters.
Examples (RMO )
This example deletes a pull subscription to a transactional publication and removes the subscription registration at
the Publisher.



try
{

// Define the publication.

// Delete the pull subscription, if it exists.

if (subscription.IsExistingObject)
{
{
// Remove the pull subscription registration at the Publisher.
publication.RemovePullSubscription(subscriberName, subscriptionDbName);
}
else
{
}
// Delete the pull subscription at the Subscriber.
subscription.Remove();
}
else
{
"The subscription to {0} does not exist on {1}",
publicationName, subscriberName));
}
}
{
"The subscription to {0} could not be deleted.", publicationName), ex);
}
finally
{
}


Try

' Define the publication.

' Delete the pull subscription, if it exists.

If subscription.IsExistingObject Then
' Remove the pull subscription registration at the Publisher.
publication.RemovePullSubscription(subscriberName, subscriptionDbName)
Else
End If
' Delete the pull subscription at the Subscriber.
subscription.Remove()
Else
"The subscription to {0} does not exist on {1}", _
publicationName, subscriberName))
End If
"The subscription to {0} could not be deleted.", publicationName), ex)
Finally
End Try
This example deletes a pull subscription to a merge publication and removes the subscription registration at the
Publisher.



try
{

// Define the publication.


{
{
publication.RemovePullSubscription(subscriberName, subscriptionDbName);
}
else
{
}
}
else
{
}
}
{
}
finally
{
}


Try

' Define the publication.



publication.RemovePullSubscription(subscriberName, subscriptionDbName)
Else
End If
Else
End If
Finally
End Try
See Also
Delete a Push Subscription
Warehouse
This topic describes how to delete a push subscription in SQL Server 2017 by using SQL Server Management
In This Topic
To delete a push subscription, using:
Transact-SQL

Delete a push subscription at the Publisher (from the Local Publications folder in SQL Server Management
Studio) or the Subscriber (from the Local Subscriptions folder). Deleting a subscription does not remove objects
or data from the subscription; they must be removed manually.
To delete a push subscription at the Publisher
3. Expand the publication associated with the subscription you want to delete.
4. Right-click the subscription, and then click Delete.
5. In the confirmation dialog box, select whether to connect to the Subscriber to delete subscription
information. If you clear the Connect to Subscriber checkbox, you should connect to the Subscriber later
to delete the information.
To delete a push subscription at the Subscriber
3. Right-click the subscription you want to delete, and then click Delete.
4. In the confirmation dialog box, select whether to connect to the Publisher to delete subscription
information. If you clear the Connect to Publisher check box, you should connect to the Publisher later to
delete the information.
Using Transact-SQL
Push subscriptions can be deleted programmatically using replication stored procedures. The stored procedures
used depend on the type of publication to which the subscription belongs.
To delete a push subscription to a snapshot or transactional publication
1. At the Publisher on the publication database, execute sp_dropsubscription (Transact-SQL). Specify
@publication and @subscriber. Specify a value of all for @article. (Optional) If the Distributor cannot be
accessed, specify a value of 1 for @ignore_distributor to delete the subscription without removing related
objects at the Distributor.
2. At the Subscriber on the subscription database, execute sp_subscription_cleanup (Transact-SQL) to remove
replication metadata in the subscription database.
To delete a push subscription to a merge publication
1. At the Publisher, execute sp_dropmergesubscription (Transact-SQL), specifying @publication,
@subscriber and @subscriber_db. (Optional) If the Distributor cannot be accessed, specify a value of 1 for
@ignore_distributor to delete the subscription without removing related objects at the Distributor.
2. At the Subscriber on the subscription database, execute sp_mergesubscription_cleanup (Transact-SQL).
Specify @publisher, @publisher_db, and @publication. This removes merge metadata from the
subscription database.
This example deletes a push subscription to a transactional publication.

-- a pull or push subscription to a transactional publication.
EXEC sp_dropsubscription
@article = N'all',
@subscriber = @subscriber;
GO
This example deletes a push subscription to a merge publication.

-- a pull or push subscription to a merge publication.
EXEC sp_dropmergesubscription
@subscriber_db = @subscriptionDB;
GO
The RMO classes that you use to delete a push subscription depend on the type of publication to which the push
subscription is subscribed.
To delete a push subscription to a snapshot or transactional publication
3. Set the PublicationName, SubscriptionDBName, SubscriberName, and DatabaseName properties.
4. Set the ServerConnection from step 1 for the ConnectionContext property.
To delete a push subscription to a merge publication
3. Set the PublicationName, SubscriptionDBName, SubscriberName, and DatabaseName properties.
4. Set the ServerConnection from step 1 for the ConnectionContext property.
Examples (RMO )
You can delete push subscriptions programmatically by using Replication Management Objects (RMO).


try
{
conn.Connect();


{
}
else
{
}
}
{
}
finally
{
conn.Disconnect();
}


Try
conn.Connect()



Else
End If
Finally
conn.Disconnect()
End Try
See Also
Warehouse
Subscriptions can be deactivated or can expire if they are not synchronized within a specified retention period.
The action that occurs depends on the type of replication and the retention period that is exceeded.
To set retention periods, see Set the Expiration Period for Subscriptions, Set the Distribution Retention Period for
Transactional Publications (SQL Server Management Studio), and Configure Publishing and Distribution.
Transactional replication uses the maximum distribution retention period (the @max_distretention parameter
of sp_adddistributiondb (Transact-SQL)) and the publication retention period (the @retention parameter of
sp_addpublication (Transact-SQL)):
If a subscription is not synchronized within the maximum distribution retention period (default of 72
hours) and there are changes in the distribution database that have not been delivered to the Subscriber,
the subscription will be marked deactivated by the Distribution clean up job that runs on the Distributor.
The subscription must be reinitialized.
If a subscription is not synchronized within the publication retention period (default of 336 hours), the
subscription will expire and be dropped by the Expired subscription clean up job that runs on the
Publisher. The subscription must be recreated and synchronized.
If a push subscription expires, it is completely removed, but pull subscriptions are not. You must clean up
pull subscriptions at the Subscriber. For more information, see Delete a Pull Subscription.
Merge Replication
Merge replication uses the publication retention period (the @retention and @retention_period_unit
parameters of sp_addmergepublication (Transact-SQL)). When a subscription expires, it must be reinitialized,
because metadata for the subscription is removed. Subscriptions that are not reinitialized are dropped by the
Expired subscription clean up job that runs on the Publisher. By default, this job runs daily; it removes all push
subscriptions that have not synchronized for double the length of the publication retention period. For example:
If a publication has a retention period of 14 days, a subscription can expire if it has not synchronized within
14 days.
If the Publisher is running SQL Server 2005 or a later version and the agent for the subscription is from
SQL Server 2005 or a later version, a subscription only expires if there have been changes to the data in
that subscription's partition. For example, suppose a Subscriber receives customer data only for customers
in Germany. If the retention period is set to 14 days, the subscription expires on day 14 only if there have
been changes to the German customer data in the last 14 days.
From 14 days to 27 days after the last synchronization, the subscription can be reinitialized.
At 28 days after the last synchronization, the subscription is dropped by the Expired subscription clean
up job. If a push subscription expires, it is completely removed, but pull subscriptions are not. You must
clean up pull subscriptions at the Subscriber. For more information, see Delete a Pull Subscription.
Considerations for Setting the Publication Retention Period for Merge Publications
Keep the following considerations in mind when setting the retention period for merge publications:
The retention period for merge publications has a 24-hour grace period to accommodate Subscribers in
different time zones. If, for example, you set a retention period of one day, the actual retention period is 48
hours.
Cleanup of merge replication metadata is dependent on the publication retention period:
Replication cannot clean up metadata in the publication and subscription databases until the
retention period is reached. Use caution in specifying a high value for the retention period, because
it can negatively impact replication performance. It is recommended that you use a lower setting if
you can reliably predict that all Subscribers will synchronize regularly within that time period.
It is possible to specify that subscriptions never expire (a value of 0 for @retention), but it is
strongly recommended that you do not use this value, because metadata cannot be cleaned up.
The retention period for any republisher must be set to a value equal to or less than the retention period
set at the original Publisher. You should also use the same publication retention values for all Publishers
and their alternate synchronization partners. Using different values may lead to non-convergence. If you
need to change the publication retention value, reinitialize the Subscriber to avoid the non-convergence of
data.
If, after a clean up, the publication retention period is increased and a subscription tries to merge with the
Publisher (which has already deleted the metadata), the subscription will not expire because of the
increased retention value. However, the Publisher does not have enough metadata to download changes
to the Subscriber, which leads to non-convergence.
See Also
Create a Subscription for a Non-SQL Server
Subscriber
Warehouse
This topic describes how to create a subscription for a non-SQL Server Subscriber in SQL Server 2017 by using
SQL Server Management Studio or Transact-SQL. Transactional and snapshot replication support publishing data
to non- SQL Server Subscribers. For information about supported Subscriber platforms, see Non-SQL Server
Subscribers.
In This Topic
To create a subscription for a non-SQL Server Subscriber, using:
Transact-SQL

To create a subscription for a non- SQL Server Subscriber:
1. Install and configure the appropriate client software and OLE DB provider(s) on the SQL Server Distributor.
For more information, see Oracle Subscribers and IBM DB2 Subscribers.
2. Create a publication using the New Publication Wizard. For more information about creating publications,
see Create a Publication and Create a Publication from an Oracle Database. Specify the following options in
the New Publication Wizard:
On the Publication Type page, select Snapshot publication or Transactional publication.
On the Snapshot Agent page, clear Create a snapshot immediately.
You create the snapshot after the publication is enabled for non- SQL Server Subscribers to ensure
that the Snapshot Agent generates a snapshot and initialization scripts that are suitable for non- SQL
Server Subscribers.
3. Enable the publication for non- SQL Server Subscribers using the Publication Properties -
<PublicationName> dialog box. See Publication Properties, Subscription Options for more information
about this step.
4. Create a subscription using the New Subscription Wizard. This topic provides more information about this
step.
5. (Optional) Change the pre_creation_cmd article property to retain tables at the Subscriber. This topic
provides more information about this step.
6. Generate a snapshot for the publication. This topic provides more information about this step.
7. Synchronize the subscription. For more information, see Synchronize a Push Subscription.
To enable a publication for non-SQL Server Subscribers
3. Right-click the publication, and then click Properties.
4. On the Subscription Options page, select a value of True for the option Allow non-SQL Server
Subscribers. Selecting this option changes a number of properties so that the publication is compatible
with non- SQL Server Subscribers.
NOTE
Selecting True sets the value of the pre_creation_cmd article property to 'drop'. This setting specifies that
replication should drop a table at the Subscriber if it matches the name of the table in the article. If you have existing
tables at the Subscriber that you want to keep, use the sp_changearticle stored procedure for each article; specify a
value 'none' for pre_creation_cmd:
sp_changearticle @publication= 'MyPublication', @article= 'MyArticle', @property='pre_creation_cmd',
@value='none'
.
5. Click OK. You will be prompted to create a new snapshot for the publication. If you do not want to create
one at this time, use the steps described in the next "how to" procedure at a later time.
To create a subscription for a non-SQL Server Subscriber
2. Right-click the appropriate publication, and then click New Subscriptions.
3. On the Distribution Agent Location page, ensure Run all agents at the Distributor is selected. Non-
SQL Server Subscribers do not support running agents at the Subscriber.
4. On the Subscribers page, click Add Subscriber and then click Add Non-SQL Server Subscriber.
5. In the Add Non-SQL Server Subscriber dialog box, select the type of Subscriber.
6. Enter a value in Data source name:
For Oracle, this is the transparent network substrate (TNS) name you configured.
For IBM, this can be any name. It is typical to specify the network address of the Subscriber.
The data source name entered in this step and the credentials specified in step 9 are not validated by
this wizard. They are not used by replication until the Distribution Agent runs for the subscription.
Ensure that all values have been tested by connecting to the Subscriber using a client tool (such as
sqlplus for Oracle). For more information, see Oracle Subscribers and IBM DB2 Subscribers.
7. Click OK. On the Subscribers page of the wizard, the Subscriber is now displayed in the Subscriber column
with a read-only (default destination) in the Subscription Database column:
For Oracle, a server has at most one database, so it is not necessary to specify the database.
For IBM DB2, the database is specified in the Initial Catalog property of the DB2 connection string,
which can be entered in the Additional connection options field described later in this process.
8. On the Distribution Agent Security page, click the properties button () next to the Subscriber to access
the Distribution Agent Security dialog box.
9. In the Distribution Agent Security dialog box:
In the Process account, Password, and Confirm password fields, enter the Microsoft Windows
account and password under which the Distribution Agent should run and make local connections to
the Distributor.
The account requires these minimum permissions: member of the db_owner fixed database role in
the distribution database; member of the publication access list (PAL); read permissions on the
snapshot share; and read permission on the install directory of the OLE DB provider. For more
information about the PAL, see Secure the Publisher.
Under Connect to the Subscriber, in the Login, Password, and Confirm password fields, enter
the login and password that should be used to connect to the Subscriber. This login should already
be configured and should have sufficient permissions to create objects in the subscription database.
In the Additional connection options field, specify any connection options for the Subscriber in
the form of a connection string (Oracle does not require additional options). Each option should be
separated by a semi-colon. The following is an example of a DB2 connection string (line breaks are
for readability):
Provider=DB2OLEDB;Initial Catalog=MY_SUBSCRIBER_DB;Network Transport Library=TCP;Host CCSID=1252;

PC Code Page=1252;Network Address=MY_SUBSCRIBER;Network Port=50000;Package Collection=MY_PKGCOL;
Default Schema=MY_SCHEMA;Process Binary as Character=False;Units of Work=RUW;DBMS
Platform=DB2/NT;
Persist Security Info=False;Connection Pooling=True;
Most of the options in the string are specific to the DB2 server you are configuring, but the Process
Binary as Character option should always be set to False. A value is required for the Initial
Catalog option to identify the subscription database.
10. On the Synchronization Schedule page, select a schedule for the Distribution Agent from the Agent
Schedule menu (the schedule is typically Run continuously).
11. On the Initialize Subscriptions page, specify whether the subscription should be initialized and, if so,
when it should be initialized:
Clear Initialize only if you have created all objects and added all required data in the subscription
database.
Select Immediately from the drop-down list in the Initialize When column to have the Distribution
Agent transfer snapshot files to the Subscriber after this wizard is completed. Select At first
synchronization to have the agent transfer the files the next time it is scheduled to run.
12. On the Wizard Actions page, optionally script the subscription. For more information, see Scripting
Replication.
To retain tables at the Subscriber
By default, enabling a publication for non- SQL Server Subscribers sets the value of the pre_creation_cmd
article property to 'drop'. This setting specifies that replication should drop a table at the Subscriber if it
matches the name of the table in the article. If you have existing tables at the Subscriber that you want to keep,
use the sp_changearticle stored procedure for each article; specify a value 'none' for pre_creation_cmd.
sp_changearticle @publication= 'MyPublication', @article= 'MyArticle', @property='pre_creation_cmd',
@value='none'
.
To generate a snapshot for the publication
2. Right-click the publication, and then click View Snapshot Agent Status.
3. In the View Snapshot Agent Status - <Publication> dialog box, click Start.
When the Snapshot Agent finishes generating the snapshot, a message is displayed, such as "[100%] A
snapshot of 17 article(s) was generated."
Using Transact-SQL
You can create push subscriptions to non- SQL Server Subscribers programmatically using replication stored
procedures.
IMPORTANT
When possible, prompt users to enter security credentials at runtime. If you must store credentials in a script file, you must
To create a push subscription for a transactional or snapshot publication to a non-SQL Server Subscriber
1. Install the most recent OLE DB provider for the non- SQL Server Subscriber at both the Publisher and
Distributor. For the replication requirements for an OLE DB provider, see Non-SQL Server Subscribers,
Oracle Subscribers, IBM DB2 Subscribers.
2. At the Publisher on the publication database, verify that the publication supports non- SQL Server
Subscribers by executing sp_helppublication (Transact-SQL).
If the value of enabled_for_het_sub is 1, non- SQL Server Subscribers are supported.
If the value of enabled_for_het_sub is 0, execute sp_changepublication (Transact-SQL), specifying
enabled_for_het_sub for @property and true for @value.
NOTE
Before changing enabled_for_het_sub to true, you must drop any existing subscriptions to the publication.
You cannot set enabled_for_het_sub to true when the publication also supports updating subscriptions.
Changing enabled_for_het_sub will affect other publication properties. For more information, see Non-SQL
Server Subscribers.
3. At the Publisher on the publication database, execute sp_addsubscription (Transact-SQL). Specify

@publication, @subscriber, a value of (default destination) for @destination_db, a value of push for
@subscription_type, and a value of 3 for @subscriber_type (specifies an OLE DB provider).
4. At the Publisher on the publication database, execute sp_addpushsubscription_agent (Transact-SQL). Specify
the following:
The @subscriberand @publication parameters.
A value of (default destination) for @subscriber_db,
The properties of the non- SQL Server data source for @subscriber_provider,
@subscriber_datasrc, @subscriber_location, @subscriber_provider_string, and
@subscriber_catalog.
The Microsoft Windows credentials under which the Distribution Agent at the Distributor runs for
NOTE
Connections made using Windows Integrated Authentication always use the Windows credentials specified
by @job_login and @job_password. The Distribution Agent always makes the local connection to the
Distributor using Windows Integrated Authentication. By default, the agent will connect to the Subscriber
using Windows Integrated Authentication.
A value of 0 for @subscriber_security_mode and the OLE DB provider login information for
@subscriber_login and @subscriber_password.
IMPORTANT
When creating a push subscription at a Publisher with a remote Distributor, the values supplied for all parameters,
including job_login and job_password, are sent to the Distributor as plain text. You should encrypt the connection
between the Publisher and its remote Distributor before executing this stored procedure. For more information, see
Enable Encrypted Connections to the Database Engine (SQL Server Configuration Manager).
See Also
IBM DB2 Subscribers
Oracle Subscribers
Other Non-SQL Server Subscribers
Specify a Merge Subscription Type and Conflict
Resolution Priority
Warehouse
Specify a merge subscription type and conflict resolution priority on the Subscription Type page of the New
Subscription Wizard. For more information about using this wizard, see Create a Pull Subscription and Create a
Push Subscription.
Subscription type cannot be modified after a subscription is created, but priority can be modified for the server
subscription type in the Subscription Properties - <Publisher>: <PublicationDatabase> dialog box. For more
information about accessing this dialog box, see View and Modify Push Subscription Properties and View and
Modify Pull Subscription Properties.
To specify a merge subscription type and conflict resolution priority
1. On the Subscription Type page of the New Subscription Wizard, select Client or Server for the
Subscription Type option.
2. If you select a subscription type of Server, also enter a value (0.00 to 99.99) for the Priority for Conflict
Resolution option.
To modify the conflict resolution priority
1. In the Subscription Properties - <Publisher>: <PublicationDatabase> at the Publisher, enter a value
(0.00 to 99.99) for the Priority option.
2. Click OK.
See Also
Advanced Merge Replication Conflict Detection and Resolution
Warehouse
This topic describes how to specify synchronization schedules in SQL Server 2017 by using SQL Server
Management Studio, Transact-SQL, or Replication Management Objects (RMO). When you create a subscription,
you can define a synchronization schedule that controls when the replication agent for the subscription will run. If
you do not specify scheduling parameters, the subscription will use the default schedule.
Subscriptions are synchronized by the Distribution Agent (for snapshot and transactional replication) or the
Merge Agent (for merge replication). Agents can run continuously, run on demand, or run on a schedule.
In This Topic
To specify synchronization schedules, using:
Transact-SQL

Specify synchronization schedules on the Synchronization Schedule page of the New Subscription Wizard. For
more information about accessing this wizard, see Create a Push Subscription and Create a Pull Subscription.
Modify synchronization schedules in the Job Schedule Properties dialog box, which is available from the Jobs
folder in SQL Server Management Studio and from the agent details windows in Replication Monitor. For
information about starting Replication Monitor, see Start the Replication Monitor.
If you specify schedules from the Jobs folder, use the following table to determine the agent job name.
AGENT JOB NAME
Merge Agent for pull subscriptions <Publisher>-<PublicationDatabase>-<Publication>-

<Subscriber>-<SubscriptionDatabase>-<integer>
Merge Agent for push subscriptions <Publisher>-<PublicationDatabase>-<Publication>-

<Subscriber>-<integer>
Distribution Agent for push subscriptions <Publisher>-<PublicationDatabase>-<Publication>-

<Subscriber>-<integer> 1
Distribution Agent for pull subscriptions <Publisher>-<PublicationDatabase>-<Publication>-

<Subscriber>-<SubscriptionDatabase>-<GUID> 2
Distribution Agent for push subscriptions to non-SQL Server <Publisher>-<PublicationDatabase>-<Publication>-

Subscribers <Subscriber>-<integer>
1 For
push subscriptions to Oracle publications, it is <Publisher>-<Publisher> rather than <Publisher>-
<PublicationDatabase>
2
2 For
pull subscriptions to Oracle publications, it is <Publisher>-<DistributionDatabase> rather than
<Publisher>-<PublicationDatabase>
To specify synchronization schedules
1. On the SynchronizationSchedule page of the New Subscription Wizard, select one of the following
values from the Agent Schedule drop-down list for each subscription you are creating:
Run continuously
Run on demand only
<Define Schedule>
2. If you select <Define Schedule>, specify a schedule in the Job Schedule Properties dialog box, and
then click OK.
3. Complete the wizard.
To modify a synchronization schedule for a push subscription in Replication Monitor
publication.
3. Right-click a subscription, and then click View Details.
4. In the Subscription < SubscriptionName> window, click Action, and then click <AgentName> Job
Properties.
5. On the Schedules page of the Job Properties - <JobName> dialog box, click Edit.
6. In the Job Schedule Properties dialog box, select a value from the Schedule Type drop-down list:
To specify that the agent should run continuously, select Start automatically when SQL Server
Agent starts.
To specify that the agent should run on a schedule, select Recurring.
To specify that the agent should run on demand, select One time.
7. If you select Recurring, specify a schedule for the agent.
8. Click OK.
To modify a synchronization schedule for a push subscription in Management Studio
1. Connect to the Distributor in Management Studio, and then expand the server node.
2. Expand the SQL Server Agent folder, and then expand the Jobs folder.
3. Right-click the job for the Distribution Agent or Merge Agent associated with the subscription, and then
click Properties.
Agent starts.
7. Click OK.
To modify a synchronization schedule for a pull subscription in Management Studio
2. Expand the SQL Server Agent folder, and then expand the Jobs folder.
3. Right-click the job for the Distribution Agent or Merge Agent associated with the subscription, and then
click Properties.
Agent starts.
7. Click OK.
Using Transact-SQL
You can define synchronization schedules programmatically using replication stored procedures. The stored
procedures that you use depend on the type of replication and the type of subscription (pull or push).
A schedule is defined by the following scheduling parameters, the behaviors of which are inherited from
sp_add_schedule (Transact-SQL):
@frequency_type - the type of frequency used when scheduling the agent.
@frequency_interval - the day of the week when an agent runs.
@frequency_relative_interval - the week of a given month when the agent is scheduled to run monthly.
@frequency_recurrence_factor - the number of frequency-type units that occur between
synchronizations.
@frequency_subday - the frequency unit when the agent runs more often than once a day.
@frequency_subday_interval - the number of frequency units between runs when the agent runs more
often than once a day.
@active_start_time_of_day - the earliest time in a given day when an agent run will start.
@active_end_time_of_day - the latest time in a given day when an agent run will start.
@active_start_date - the first day that the agent schedule will be in effect.
@active_end_date - the last day that the agent schedule will be in effect.
To define the synchronization schedule for a pull subscription to a transactional publication
1. Create a new pull subscription to a transactional publication. For more information, see Create a Pull
Subscription.
2. At the Subscriber, execute sp_addpullsubscription_agent (Transact-SQL). Specify @publisher,
@publisher_db, @publication, and the Microsoft Windows credentials under which the Distribution
Agent at the Subscriber runs for @job_name and @password. Specify the synchronization parameters,
detailed above, that define the schedule for the Distribution Agent job that synchronizes the subscription.
To define the synchronization schedule for a push subscription to a transactional publication
1. Create a new push subscription to a transactional publication. For more information, see Create a Push
Subscription.
2. At the Subscriber, execute sp_addpushsubscription_agent (Transact-SQL). Specify @subscriber,
@subscriber_db, @publication, and the Windows credentials under which the Distribution Agent at the
Subscriber runs for @job_name and @password. Specify the synchronization parameters, detailed
above, that define the schedule for the Distribution Agent job that synchronizes the subscription.
To define the synchronization schedule for a pull subscription to a merge publication
1. Create a new pull subscription to a merge publication. For more information, see Create a Pull
Subscription.
2. At the Subscriber, execute sp_addmergepullsubscription_agent. Specify @publisher, @publisher_db,
@publication, and the Windows credentials under which the Merge Agent at the Subscriber runs for
@job_name and @password. Specify the synchronization parameters, detailed above, that define the
schedule for the Merge Agent job that synchronizes the subscription.
To define the synchronization schedule for a push subscription to a merge publication
1. Create a new push subscription to a merge publication. For more information, see Create a Push
Subscription.
2. At the Subscriber, execute sp_addmergepushsubscription_agent. Specify @subscriber, @subscriber_db,
@publication, and the Windows credentials under which the Merge Agent at the Subscriber runs for
@job_name and @password. Specify the synchronization parameters, detailed above, that define the
schedule for the Merge Agent job that synchronizes the subscription.

Replication uses the SQL Server Agent to schedule jobs for activities that occur periodically, such as snapshot
generation and subscription synchronization. You can use Replication Management Objects (RMO)
programmatically to specify schedules for replication agent jobs.
NOTE
When you create a subscription and specify a value false for CreateSyncAgentByDefault (the default behavior for pull
subscriptions) the agent job is not created and scheduling properties are ignored. In this case, the synchronization schedule
must be determined by the application. For more information, see Create a Pull Subscription and Create a Push
Subscription.
To define a replication agent schedule when you create a push subscription to a transactional publication
1. Create an instance of the TransSubscription class for the subscription you are creating. For more
information, see Create a Push Subscription.
2. Before you call Create, set one or more of the following fields of the AgentSchedule property:
FrequencyType - the type of frequency (such as daily or weekly) you use when you schedule the
agent.
FrequencyInterval - the day of the week that an agent runs.
FrequencyRelativeInterval - the week of a given month when the agent is scheduled to run monthly.
FrequencyRecurrenceFactor - the number of frequency-type units that occur between
synchronizations.
FrequencySubDay - the frequency unit when the agent runs more often than once a day.
FrequencySubDayInterval - the number of frequency units between runs when the agent runs more
ActiveStartTime - earliest time on a given day that an agent run starts.
ActiveEndTime - latest time on a given day that an agent run starts.
ActiveStartDate - first day that the agent schedule is in effect.
ActiveEndDate - last day that the agent schedule is in effect.
NOTE
If you do not specify one of these properties, a default value is set.
3. Call the Create method to create the subscription.

To define a replication agent schedule when you create a pull subscription to a transactional publication
1. Create an instance of the TransPullSubscription class for the subscription you are creating. For more
information, see Create a Pull Subscription.
FrequencyType - the type of frequency (such as daily or weekly) that you use when you schedule
the agent.
FrequencyRelativeInterval - the week of a given month that the agent is scheduled to run monthly.
synchronizations.
NOTE

To define a replication agent schedule when you create a pull subscription to a merge publication
1. Create an instance of the MergePullSubscription class for the subscription you are creating. For more
the agent.
synchronizations.
NOTE

To define a replication agent schedule when you create a push subscription to a merge publication
1. Create an instance of the MergeSubscription class for the subscription you are creating. For more
the agent.
synchronizations.
NOTE

Example (RMO )
This example creates a push subscription to a merge publication and specifies the schedule on which the
subscription is synchronized.



try
{
conn.Connect();

{
{
}

// Set a schedule to synchronize the subscription every 2 hours

// during weekdays from 6am to 10pm.
subscription.AgentSchedule.FrequencyType = ScheduleFrequencyType.Weekly;
subscription.AgentSchedule.FrequencyInterval = Convert.ToInt32(0x003E);
subscription.AgentSchedule.FrequencyRecurrenceFactor = 1;
subscription.AgentSchedule.FrequencySubDay = ScheduleFrequencySubDay.Hour;
subscription.AgentSchedule.FrequencySubDayInterval = 2;
subscription.AgentSchedule.ActiveStartDate = 20051108;
subscription.AgentSchedule.ActiveEndDate = 20071231;
subscription.AgentSchedule.ActiveStartTime = 060000;
subscription.AgentSchedule.ActiveEndTime = 100000;

}
else
{
}
}
{
}
finally
{
conn.Disconnect();
}



Try
conn.Connect()

End If

' Set a schedule to synchronize the subscription every 2 hours
' during weekdays from 6am to 10pm.
subscription.AgentSchedule.FrequencyType = ScheduleFrequencyType.Weekly
subscription.AgentSchedule.FrequencyInterval = Convert.ToInt32("0x003E", 16)
subscription.AgentSchedule.FrequencyRecurrenceFactor = 1
subscription.AgentSchedule.FrequencySubDay = ScheduleFrequencySubDay.Hour
subscription.AgentSchedule.FrequencySubDayInterval = 2
subscription.AgentSchedule.ActiveStartDate = 20051108
subscription.AgentSchedule.ActiveEndDate = 20071231
subscription.AgentSchedule.ActiveStartTime = 60000
subscription.AgentSchedule.ActiveEndTime = 100000

Else

End If
Finally
conn.Disconnect()
End Try
See Also
Synchronize Data
Warehouse
Subscribers in a replication topology must be initialized, so that they have a copy of the schema from each article
in the publication they have subscribed to and any replication objects that are required, such as stored
procedures, triggers, and metadata tables. In addition, the Subscriber typically receives an initial dataset. The
default initialization method uses a full snapshot that includes schema, replication objects, and data, but
publications can also be initialized without a full snapshot.
For more information, see Initialize a Subscription with a Snapshot and Initialize a Transactional Subscription
Without a Snapshot.
Warehouse
After a publication has been created, an initial snapshot is typically created and copied to the snapshot folder
(this occurs by default for merge publications created with the New Publication Wizard). It is then applied to the
Subscriber by the Distribution Agent (for transactional and snapshot publications) or the Merge Agent (for
merge publications) during the initial synchronization of the subscription. The snapshot process depends on the
type of publication:
If the snapshot is for a snapshot publication, a transactional publication, or a merge publication that
doesn't use parameterized filters, the snapshot contains the schema and data in bulk copy program (bcp)
files, as well as constraints, extended properties, indexes, triggers, and the system tables necessary for
replication. For more information about creating and applying the snapshot, see Create and Apply the
Snapshot.
If the snapshot is for a merge publication that uses parameterized filters, the snapshot is created using a
two-part process. First a schema snapshot is created that contains the replication scripts and the schema
of the published objects, but not the data. Each subscription is then initialized with a snapshot that
includes the scripts and schema copied from the schema snapshot and the data that belongs to the
subscription's partition. For more information, see Snapshots for Merge Publications with Parameterized
Filters.
The snapshot consists of different files depending on the type of replication and the articles in your
publication. These files are copied to the default snapshot folder specified when the Distributor was
configured or the alternate snapshot folder specified when the publication was created.
TYPE OF REPLICATION COMMON SNAPSHOT FILES
Snapshot Replication or Transactional Replication schema (.sch); data (.bcp); constraints and indexes (.dri);
constraints (.idx); triggers (.trg):for updating Subscribers only;
compressed snapshot files (.cab).
Merge Replication schema (.sch); data (.bcp); constraints and indexes (.dri);
triggers (.trg); system table data (.sys); conflict tables (.cft);
compressed snapshot files (.cab).
If the snapshot transfer is interrupted at any point, it will automatically resume and will not resend any files that
have already been completely transferred. The unit of delivery for the Snapshot Agent is the bcp file for each
publication article, so files that are partially delivered must be completely redelivered. However, resuming the
snapshot can significantly reduce the amount of data transmitted and ensure timely snapshot delivery even if the
connection is unreliable.
Snapshot Options
There are a number of options available when initializing a subscription with a snapshot. You can:
Specify an alternate snapshot folder location instead of, or in addition, to the default snapshot folder
location. For more information, see Alternate Snapshot Folder Locations.
Compress snapshots for storage on removable media or for transfer over a slow network. For more
information, see Compressed Snapshots.
Execute Transact-SQL scripts before or after the snapshot is applied. For more information, see Execute
Scripts Before and After the Snapshot Is Applied.
Transfer snapshot files using File Transfer Protocol (FTP). For more information, see Transfer Snapshots
Through FTP.
See Also
Secure the Snapshot Folder
Create and Apply the Snapshot
Warehouse
Snapshots are generated by the Snapshot Agent after a publication is created. They can be generated:
Immediately. By default, a snapshot for a merge publication is generated immediately after the publication
is created in the New Publication Wizard.
At a scheduled time. Specify a schedule on the Snapshot Agent page of the New Publication Wizard or
when using stored procedures or Replication Management Objects (RMO).
Manually. Run the Snapshot Agent from the command prompt or from SQL Server Management Studio.
For more information about running agents, see Replication Agent Executables Concepts and Start and Stop
a Replication Agent (SQL Server Management Studio).
For merge replication, a snapshot is generated every time the Snapshot Agent runs. For transactional
replication, snapshot generation depends on the setting of the publication property immediate_sync. If the
property is set to TRUE (the default when using the New Publication Wizard), a snapshot is generated every
time the Snapshot Agent runs, and it can be applied to a Subscriber at any time. If the property is set to
FALSE (the default when using sp_addpublication), the snapshot is generated only if a new subscription
has been added since the last Snapshot Agent run; Subscribers must wait for the Snapshot Agent to
complete before they can synchronize.
By default, when snapshots are generated, they are saved in the default snapshot folder located on the
Distributor. You can also save snapshot files on removable media such as removable disks, CD-ROMs, or in
locations other than in the default snapshot folder. Additionally, you can compress the files so that they are
easier to store and transfer, and execute scripts before or after the snapshot is applied at the Subscriber. For
more information about these options, see Snapshot Options.
If the snapshot is for a merge publication that uses parameterized filters, the snapshot is created using a
two-part process. First a schema snapshot is created that contains the replication scripts and the schema of
the published objects, but not the data. Each subscription is then initialized with a snapshot that includes the
scripts and schema copied from the schema snapshot and the data that belongs to the subscription's
partition. For more information, see Snapshots for Merge Publications with Parameterized Filters.
After the snapshot is created at the Publisher and stored in a default or alternate snapshot location, the
snapshot can be transferred to the Subscriber and applied. The Distribution Agent (for snapshot or
transactional replication) or Merge Agent (for merge replication) transfers the snapshot and applies the
schema and data files to the subscription database on the Subscriber during the initial synchronization. By
default, the initial synchronization occurs immediately after a subscription is created if you use the New
Subscription Wizard. This behavior is controlled by the Initialize When option on the Initialize
Subscriptions page of the wizard. When snapshots are generated after a subscription is initialized, they are
not applied to a Subscriber unless a subscription is marked for reinitialization. For more information, see
Reinitialize Subscriptions.
After the Distribution Agent or Merge Agent applies the initial snapshot, the agent propagates subsequent
updates and other data modifications. When snapshots are distributed and applied to Subscribers, only
those Subscribers waiting for initial or new snapshots are affected. Other Subscribers to that publication
(those that are already receiving inserts, updates, deletes, or other modifications to the published data) are
not affected.
To create and apply the initial snapshot, Create and Apply the Initial Snapshot.
To view or modify the default snapshot folder location, see
SQL Server Management Studio: Specify the Default Snapshot Location (SQL Server Management Studio)
Replication Programming and RMO programming: Configure Publishing and Distribution
See Also
sp_addpublication (Transact-SQL)
Snapshots for Merge Publications with
Parameterized Filters
Warehouse
When parameterized row filters are used in merge publications, replication initializes each subscription with a
two-part snapshot. First, a schema snapshot is created that contains all objects required by replication and the
schema of the published objects, but not the data. Then, each subscription is initialized with a snapshot that
includes the objects and schema from the schema snapshot and the data that belongs to the subscription's
partition. If more than one subscription receives a given partition (in other words, they receive the same schema
and data), the snapshot for that partition is created only once; multiple subscriptions are initialized from the same
snapshot. For more information about parameterized row filters, see Parameterized Row Filters.
You can create snapshots for publications with parameterized filters in one of three ways:
Pre-generate snapshots for each partition. Using this option allows you to control when snapshots are
generated.
You can also choose to have the snapshots refreshed on a schedule. New Subscribers that subscribe to a
partition for which a snapshot has been created will receive an up-to-date snapshot.
Allow Subscribers to request snapshot generation and application the first time they synchronize. Using this
option allows new Subscribers to synchronize without requiring intervention from an administrator ( SQL
Server Agent must be running at the Publisher to allow the snapshot to be generated).
NOTE
If the filtering for one or more articles in the publication yields non-overlapping partitions that are unique for each
subscription, metadata is cleaned up whenever the Merge Agent runs. This means that the partitioned snapshot
expires more quickly. When using this option, you should consider allowing Subscribers to initiate snapshot
generation and delivery. For more information about filtering options, see Parameterized Row Filters.
Manually generate a snapshot for each Subscriber with the Snapshot Agent. The Subscriber must then
provide the snapshot location to the Merge Agent, so it can retrieve and apply the correct snapshot.
NOTE
This option is supported for backward compatibility and does not allow FTP snapshot shares.
The most flexible approach is to use a combination of pre-generated and Subscriber-requested snapshot
options: snapshots are pre-generated and refreshed on a scheduled basis (usually during off-peak times),
but a Subscriber can generate its own snapshot if a subscription that requires a new partition is created.
Consider Adventure Works, which has a mobile work force that delivers inventory to individual stores. Each
sales person receives a subscription based on their login, which retrieves the data for the stores they
service. The administrator chooses to pre-generate snapshots and refresh them every Sunday. Occasionally
a new user is added to the system and needs data for a partition that does not have a snapshot available.
The administrator also chooses to allow Subscriber-initiated snapshots to avoid the situation where a
Subscriber cannot subscribe to the publication because the snapshot is not yet available. When the new
Subscriber connects for the first time, the snapshot is generated for the specified partition and applied at
the Subscriber ( SQL Server Agent must be running at the Publisher to allow the snapshot to be generated).
To create a snapshot for a publication with parameterized filters, see Create a Snapshot for a Merge
Publication with Parameterized Filters.
Security Settings for the Snapshot Agent

The Snapshot Agent creates snapshots for each partition. For pre-generated snapshots and snapshots requested
by a Subscriber, the agent runs and makes connections under the credentials that were specified when the
snapshot agent job for the publication was created (the job is created by the New Publication Wizard or
sp_addpublication_snapshot). To change the credentials, use sp_changedynamicsnapshot_job. For more
information, see sp_changedynamicsnapshot_job (Transact-SQL).
See Also
Parameterized Row Filters
Snapshot Options
Warehouse
There are a number of options available when initializing a subscription with a snapshot:
Specify an alternate snapshot folder location instead of or in addition to the default snapshot folder location.
For more information, see Alternate Snapshot Folder Locations.
Compress snapshots for storage on removable media or for transfer over a slow network. For more
information, see Compressed Snapshots.
Execute Transact-SQL scripts before or after the snapshot is applied. For more information, see Execute
Scripts Before and After the Snapshot Is Applied.
Transfer snapshot files using File Transfer Protocol (FTP). For more information, see Transfer Snapshots
Through FTP.
See Also
Warehouse
Alternate snapshot locations enable you to store snapshot files in a location other than, or in addition to, the
default location, which is typically located on the Distributor. Alternate locations can be on another server, on a
network drive, or on removable media such as CD-ROMs or removable disks.
Alternate snapshot locations are stored as a property of the publication. Because the alternate snapshot location is
a publication property, the Distribution Agent and the Merge Agent are able to locate the proper snapshot as part
of the synchronization process.
If you want to specify an alternate snapshot folder location or if you want to compress snapshot files, create the
publication without creating the initial snapshot immediately, set the publication properties for the snapshot
location, and then run the Snapshot Agent for that publication. If you change the alternate location after creating
the initial snapshot, the location of any generated snapshot for the publication will not be relocated to the new
alternate location. In this case, depending on the publication settings, the Merge Agent or Distribution Agent might
not be able to find the snapshot files at the new alternate location.
NOTE
Do not specify an alternate location (using the Publication Properties dialog box or sp_changepublication (Transact-SQL))
that is the same as the default snapshot folder location.
Cau t i on
Do not use both WebSync and alternate snapshot folder locations at the same time.
To specify alternate snapshot locations
SQL Server Management Studio: Specify an Alternate Snapshot Folder Location (SQL Server Management
Studio)
Replication Transact-SQL programming: Configure Snapshot Properties (Replication Transact-SQL
Programming)
See Also
Snapshot Options
Compressed Snapshots
Warehouse
Compressing snapshot files is appropriate when you are transferring snapshots over a slow network or you are
saving them to removable media and an uncompressed snapshot is too large to fit on the media. Compressing
snapshot files is useful in these situations, but compression increases the time to generate and apply the snapshot.
Compressed snapshot files are written in the Microsoft CAB file format, which can compress files of 2 GB or less (if
the snapshot files are larger than 2GB, they cannot be compressed). To compress files, they must be written to an
alternate snapshot folder (files written to the default snapshot folder cannot be compressed). For more information
on alternate snapshot folders, see Alternate Snapshot Folder Locations.
Files are uncompressed at the location where the Distribution Agent or Merge Agent runs; pull subscriptions are
typically used with compressed snapshots so that files are uncompressed at the Subscriber. When the Subscriber
receives a compressed file, the file is written initially to a temporary location. After the compressed file is copied to
the Subscriber, the snapshot files in the compressed file are decompressed, in order, one file at a time by the CAB
utility. Space required at the Subscriber is the size of the compressed file plus the largest uncompressed file.
NOTE
Compressed snapshots can, in some cases, improve the performance of transferring snapshot files across the network.
However, compressing the snapshot requires additional processing by the Snapshot Agent when generating the snapshot
files, and by the Distribution Agent or Merge Agent when applying the snapshot files. This may slow down snapshot
generation and increase the time it takes to apply a snapshot in some cases. Additionally, compressed snapshots cannot be
resumed if a network failure occurs; therefore they are not suitable for unreliable networks. Consider these tradeoffs carefully
when using compressed snapshots across a network.
To compress and deliver snapshot files

Microsoft SQL Server Management Studio: Compress Snapshot Files (SQL Server Management Studio)
Programming)
See Also
Snapshot Options
Execute Scripts Before and After the Snapshot Is
Applied
Warehouse
You can specify scripts to execute at the Subscriber before or after the snapshot is applied. Scripts can be used for
a variety of reasons, such as creating logins and schemas (object owners) at each Subscriber.
You specify a file location for each script, and the Snapshot Agent copies the script files to the current snapshot
folder each time snapshot processing occurs. The Distribution Agent or the Merge Agent runs the pre-snapshot
script before any of the replicated object scripts when applying a snapshot. The Distribution Agent or the Merge
Agent runs the post-snapshot script after all the other replicated object scripts and data have been applied. After
the snapshot application is complete and script files run successfully, the script files are removed from the working
directory on the Subscriber.
The script is run by launching the sqlcmd utility. Before deploying a script, run it with sqlcmd to ensure it executes
as expected. The contents of scripts that are executed before and after the snapshot is applied must be repeatable.
For example, if you create a table in the script, you should first check for its existence and take appropriate action if
it exists. The script must be repeatable because if you need to reinitialize a subscription for which the script has
already been applied, the script will be applied again when the new snapshot is applied during reinitialization.
If you are compressing the snapshot file (by putting it in Microsoft CAB file format), the scripts are also
compressed and placed in the CAB file. After the compressed snapshot file is transferred to the Subscriber and
decompressed to a working directory on the Subscriber, any script indicated as a pre-snapshot script is executed.
Likewise, any post-snapshot script is decompressed and executed at the Subscriber as the last step in applying the
snapshot.
To execute scripts before and after the snapshot is applied
SQL Server Management Studio: How to: Execute Scripts Before and After a Snapshot is Applied (SQL
Programming)
See Also
Snapshot Options
Transfer Snapshots Through FTP
Warehouse
By default, snapshots are stored in folders defined as Universal Naming Convention (UNC) shares. Replication also
allows you to specify a File Transfer Protocol (FTP) share instead of a UNC share. To use FTP, you must configure
an FTP server and then configure a publication and one or more subscriptions to use FTP. For information about
how to configure an FTP server, see the Internet Information Services (IIS) documentation. If you specify FTP
information for a publication, subscriptions to that publication use FTP by default. FTP is only used with Web
synchronization when the computer that is running IIS is separated from the Distributor by a firewall. In this case,
FTP can be used to transfer the snapshot from the Distributor and the computer that is running IIS. (The snapshot
is always transferred to the Subscriber by using HTTPS.)
IMPORTANT
We recommend that you use Microsoft Windows Authentication and a UNC share rather than an FTP share because FTP
passwords must be stored, and the password is sent from the Subscriber or the computer that is running IIS when it uses
Web synchronization to the FTP server in plain text. Additionally, because a single account controls access to the snapshot
share, it is not possible to ensure that a Subscriber to a filtered merge publication only has access to the snapshot files from
their data partition.
To deliver a snapshot through FTP, see Deliver a Snapshot Through FTP.
See Also
Snapshot Options
Initialize a Transactional Subscription Without a
Snapshot
Warehouse
By default, a subscription to a transactional publication is initialized with a snapshot, which is generated by the
Snapshot Agent and applied by the Distribution Agent. In some scenarios, such as those involving large initial
datasets, it is preferable to initialize a subscription using another method. Other methods of initializing a
Subscriber include:
Specifying a backup. Restore the backup on the Subscriber, and then the Distribution Agent copies any
required replication metadata and system procedures. Initializing with a backup is the fastest way to
deliver data to the Subscriber and is convenient, because any recent backup can be used if it was taken
after the publication was enabled for initialization with a backup.
Copying an initial dataset to the Subscriber through another mechanism, such as attaching a database. You
must ensure the correct data and schema are at the Subscriber, and then the Distribution Agent copies any
required metadata and system procedures.
Initializing a subscription with a backup

A backup contains an entire database; therefore each subscription database will contain a complete copy of the
publication database when it is initialized:
The backup includes tables not specified as articles for the publication.
The backup includes all data, even if row or column filters are specified on a table.
It is the responsibility of the administrator or application to remove any unwanted objects or data after the
backup has been restored. In subsequent synchronizations, data changes are only replicated if they apply
to tables specified as articles, and the changes meet any filtering criteria you specified.
NOTE
When restoring a backup, you must ensure that the backup came from the Publisher if you want the Subscriber to
automatically synchronize. The log sequence number (LSN) values in the backup (which are used to set the point at which
to start synchronizing) are specific to the Publisher.
To initialize a subscription with a backup

To initialize a subscription with a backup, you first must enable the option when you create a publication, and
then specify values for a number of options when you create a subscription. Publications can be enabled through
the New Publication Wizard or programmatically. However, the values required for the subscription options can
only be specified programmatically.
SQL Server Management Studio: Enable Initialization with a Backup for Transactional Publications (SQL
Replication Transact-SQL programming: Initialize a Transactional Subscription from a Backup (Replication
NOTE
If a subscription is initialized without using a snapshot, the account under which the SQL Server service runs at the
Publisher must have write permissions on the snapshot folder at the Distributor. For more information about permissions,
see Replication Agent Security Model.
Ensuring the suitability of a backup

A backup is suitable for initializing a Subscriber if all transactions that occur after the backup was taken are stored
at the Distributor. Replication will display an error message if the backup is not suitable.
To help ensure that a backup is suitable for use, follow these guidelines:
Use the latest backup available, and if the latest backup is older than the maximum distribution retention
period, create a new backup before attempting to initialize a subscription with a backup. For more
information about retention period, see Subscription Expiration and Deactivation.
By default, the distribution cleanup job clears transactions older than 72 hours from the distribution
database. Cleanup is based on the retention period set for the publication. When synchronizing with older
backups, consider temporarily disabling the job before the backup you would like to restore and re-
enabling it after the subscription is successfully created. This prevents removal of transactions from the
distribution database that might be needed to synchronize successfully from the backup. For information
about running cleanup jobs, see Run Replication Maintenance Jobs (SQL Server Management Studio).
In some cases you must manually perform customizations in the restored Subscriber database after
setting up subscriptions that are initialized with a backup. In general, manual modifications at the restored
Subscriber database are required if the Publication is defined in such a way that the Subscriber database
content is expected to be different from the Publisher database content.
Indexed-views at the restored database have to be converted to tables if they are published as log-based
indexed-view-to-table articles
Subscribed timestamp columns at the restored database must be converted to binary(8) columns: copy
the content of the tables containing timestamp columns to new tables with matching schemas except
having binary(8) columns in place of the timestamp columns, drop the original tables, and rename the
new tables with the same names as the original tables.
Initializing a subscription with an alternative method

It is possible to initialize a subscription using any method that allows you to copy the publication database
schema and data to the Subscriber, such as Integration Services. When you use an alternative method to initialize
the Subscriber, replication support objects are copied to the Subscriber.
Unlike initializing with a backup, you or your application must ensure the data and schema are properly
synchronized at the time you add the subscription. If, for example, there is activity on the Publisher between the
time data and schema are copied to the Subscriber and the time at which the subscription is added, changes
resulting from this activity might not be replicated to the Subscriber.
To initialize a subscription with an alternative method, see Initialize a Subscription Manually.
See Also
Warehouse
Reinitializing a subscription involves applying a new snapshot of one or more articles to one or more Subscribers:
transactional and snapshot replication allow individual articles to be reinitialized; merge replication requires all
articles to be reinitialized. Nodes in a peer-to-peer transactional replication topology cannot be reinitialized. If you
need to ensure a node has a new copy of the data, restore a backup at the node. Reinitialization occurs for one of
two reasons:
You explicitly mark a subscription for reinitialization.
You perform an action, such as a property change, that requires a reinitialization. For more information
about actions that require reinitialization, see Change Publication and Article Properties.
In both cases, the most recent snapshot is applied to the Subscriber the next time the Distribution Agent or
the Merge Agent runs. For snapshot and transactional replication, when reinitialization occurs, any changes
made at the Subscriber, but not yet synchronized with the Publisher, are overwritten by the application of
the new snapshot.
For merge replication, you can choose to have all the data changes uploaded from the Subscriber before
the snapshot is applied. Any pending schema changes from the Publisher are applied at the Subscriber, and
then any updates that have been made at the Subscriber since the last synchronization are propagated to
the Publisher before the snapshot is reapplied. This behavior is controlled by the upload_first and
automatic_reinitialization_policy properties; for more information, see Reinitialize a Subscription. If you
mark a subscription for reinitialization using SQL Server Management Studio or Replication Monitor, you
are given an option in the Reinitialize Subscription(s) dialog box to upload changes first.
IMPORTANT
If you add, drop, or change a parameterized filter in a merge publication, pending changes at the Subscriber cannot be
uploaded to the Publisher during reinitialization. If you want to upload pending changes, synchronize all subscriptions
before changing the filter.
If, you specified that no initial snapshot was to be applied to the Subscriber when you created the subscription,
and you then mark the subscription for reinitialization, a snapshot is not applied. For more information, see
Initialize a Transactional Subscription Without a Snapshot.
To reinitialize a subscription
To reinitialize all articles in a subscription, use SQL Server Management Studio, stored procedures or Replication
Management Objects (RMO). To reinitialize individual articles in snapshot and transactional publications, you
must use stored procedures. For more information, see Reinitialize a Subscription.
See Also
Synchronize Subscriptions (Replication)
Warehouse
Subscriptions are synchronized by replication agents. The Distribution Agent synchronizes subscriptions to
transactional and snapshot publications, and the Merge Agent synchronizes subscriptions to merge publications.
You can use SQL Server Management Studio, replication stored procedures, and Replication Management Objects
(RMO) to synchronize subscriptions and to control synchronization behavior. The following topics describe how
synchronize subscriptions and specify synchronization options.
In This Section
Create a Snapshot for a Merge Publication with Parameterized Filters
Enable Initialization with a Backup for Transactional Publications (SQL Server Management Studio)
Initialize a Transactional Subscription from a Backup (Replication Transact-SQL Programming)
Execute Scripts Before and After a Snapshot Is Applied (SQL Server Management Studio)
Execute Scripts During Synchronization (Replication Transact-SQL Programming)
View and Resolve Data Conflicts for Merge Publications (SQL Server Management Studio)
Synchronize a Subscription Using Windows Synchronization Manager (Windows Synchronization Manager)
Debug a Business Logic Handler (Replication Programming)
Control the Behavior of Triggers and Constraints During Synchronization (Replication Transact-SQL
Programming)
See Also
Synchronize Data
Warehouse
This topic describes how to create and apply the initial snapshot in SQL Server 2017 by using SQL Server
Management Studio, Transact-SQL, or Replication Management Objects (RMO). Merge publications that use
parameterized filters require a two-part snapshot. For more information, see Create a Snapshot for a Merge
Publication with Parameterized Filters.
In This Topic
To create and apply the initial snapshot, using:
Transact-SQL

By default, if SQL Server Agent is running, a snapshot is generated by the Snapshot Agent immediately after a
publication is created with the New Publication Wizard. By default, it is then applied by the Distribution Agent
(for snapshot and transactional replication) or Merge Agent (for merge subscriptions) for all subscriptions. A
snapshot can also be generated using SQL Server Management Studio and Replication Monitor. For information
about starting Replication Monitor, see Start the Replication Monitor.
To create a snapshot in Management Studio
3. Right-click the publication for which you want to create a snapshot, and then click View Snapshot Agent
Status.
When the Snapshot Agent finishes generating the snapshot, a message will be displayed, such as "[100%]
A snapshot of 17 article(s) was generated."
To create a snapshot in Replication Monitor
1. In Replication Monitor, expand a Publisher group in the left pane, and then expand a Publisher.
2. Right-click the publication for which you want to generate a snapshot, and then click Generate Snapshot.
3. To view the status of the Snapshot Agent, click the Agents tab. For more detailed information, right-click
the Snapshot Agent in the grid, and then click View Details.
To apply a snapshot
1. After the snapshot is generated, it is applied by synchronizing the subscription with the Distribution Agent
or the Merge Agent:
If the agent is set to run continuously (the default for transactional replication), the snapshot is
automatically applied after it is generated.
If the agent is set to run on a schedule, the snapshot is applied the next time the agent is scheduled
to run.
If the agent is set to run on demand, it is applied the next time you run the agent.
For more information about synchronizing subscriptions, see Synchronize a Push Subscription and
Synchronize a Pull Subscription.
Using Transact-SQL
Initial snapshots can be programmatically created either by creating and running a Snapshot Agent job or by
running the Snapshot Agent executable file from a batch file. After an initial snapshot has been generated, it is
transferred to and applied at the Subscriber when the subscription is first synchronized. If you run the Snapshot
Agent from a command prompt or a batch file, you will need to rerun the agent whenever the existing snapshot
becomes invalid.
IMPORTANT
When possible, prompt users to enter security credentials at runtime. If you must store credentials in a script file, you must
To create and run a Snapshot Agent job to generate the initial snapshot
1. Create a snapshot, transactional, or merge publication. For more information, see Create a Publication.
2. Execute sp_addpublication_snapshot (Transact-SQL). Specify @publication and the following
parameters:
The @job_login, which specifies the Windows Authentication credentials under which the
Snapshot Agent runs at the Distributor.
The @job_password, which is the password for the supplied Windows credentials.
(Optional) A value of 0 for @publisher_security_mode if the agent will use SQL Server
Authentication when connecting to the Publisher. In this case, you must also specify the SQL Server
Authentication login information for @publisher_login and @publisher_password.
(Optional) A synchronization schedule for the Snapshot Agent job. For more information, see
Specify Synchronization Schedules.
IMPORTANT
When configuring a Publisher with a remote Distributor, the values supplied for all parameters, including job_login
and job_password, are sent to the Distributor as plain text. You should encrypt the connection between the
Publisher and its remote Distributor before executing this stored procedure. For more information, see Enable
Encrypted Connections to the Database Engine (SQL Server Configuration Manager).
4. At the Publisher on the publication database, execute sp_startpublication_snapshot (Transact-SQL),
specifying the value of @publication from step 1.
To run the Snapshot Agent to generate the initial snapshot
1. Create a snapshot, transactional, or merge publication. For more information, see Create a Publication.
3. From the command prompt or in a batch file, start the Replication Snapshot Agent by running
snapshot.exe, specifying the following command-line arguments:
-Publication
-Publisher
-Distributor
-PublisherDB
-ReplicationType
If you are using SQL Server Authentication, you must also specify the following arguments:
-DistributorLogin
-DistributorPassword
-DistributorSecurityMode = 0
-PublisherLogin
-PublisherPassword
-PublisherSecurityMode = 0
This example shows how to create a transactional publication and add a Snapshot Agent job for the new
publication (using sqlcmd scripting variables). The example also starts the job.
-- To avoid storing the login and password in the script file, the values
-- are passed into SQLCMD as scripting variables. For information about
-- how to use scripting variables on the command line and in SQL Server
-- Management Studio, see the "Executing Replication Scripts" section in
-- the topic "Programming Replication Using System Stored Procedures".

DECLARE @login AS sysname;
DECLARE @password AS sysname;
SET @publicationDB = N'AdventureWorks2012'; --publication database
SET @publication = N'AdvWorksCustomerTran'; -- transactional publication name
SET @login = $(Login);
SET @password = $(Password);
-- Enable transactional and snapshot replication on the publication database.

EXEC sp_replicationdboption
@dbname = @publicationDB,
@optname = N'publish',
@value = N'true';
-- Execute sp_addlogreader_agent to create the agent job.

EXEC sp_addlogreader_agent
@job_login = @login,
@job_password = @password,
-- Explicitly specify the security mode used when connecting to the Publisher.
@publisher_security_mode = 1;
-- Create new transactional publication, using the defaults.

EXEC sp_addpublication
@description = N'transactional publication';
-- Create a new snapshot job for the publication, using the defaults.
EXEC sp_addpublication_snapshot
@job_password = @password;
-- Start the Snapshot Agent job.

EXEC sp_startpublication_snapshot @publication = @publication;
GO
This example creates a merge publication and adds a Snapshot Agent job (using sqlcmd variables) for the
publication. This example also starts the job.
-- To avoid storing the login and password in the script file, the value
-- is passed into SQLCMD as a scripting variable. For information about

DECLARE @login AS sysname;
DECLARE @password AS sysname;
SET @login = $(Login);
SET @password = $(Password);
-- Enable merge replication on the publication database.

USE master
@dbname = @publicationDB,
@optname=N'merge publish',
@value = N'true';
-- Create new merge publication, using the defaults.

EXEC sp_addmergepublication
@description = N'Merge publication.';
-- Create a new snapshot job for the publication, using the defaults.
@job_password = @password;
-- Start the Snapshot Agent job.

EXEC sp_startpublication_snapshot @publication = @publication;
GO
The following command-line arguments start the Snapshot Agent to generate the snapshot for a merge
publication.
NOTE
Line breaks were added to improve readability. In a batch file, commands must be made in a single line.
REM -- Declare variables

SET Publisher=%InstanceName%
SET PublicationDB=AdventureWorks2012
SET Publication=AdvWorksSalesOrdersMerge
REM --Start the Snapshot Agent to generate the snapshot for AdvWorksSalesOrdersMerge.
"C:\Program Files\Microsoft SQL Server\120\COM\SNAPSHOT.EXE" -Publication %Publication%
-Publisher %Publisher% -Distributor %Publisher% -PublisherDB %PublicationDB%
-ReplicationType 2 -OutputVerboseLevel 1 -DistributorSecurityMode 1

The Snapshot Agent generates snapshots after a publication is created. You can generate these snapshots
programmatically by using Replication Management Objects (RMO) and direct managed code access to
replication agent functionalities. The objects you use depend on the type of replication. The Snapshot Agent can
be started synchronously using the Microsoft.SqlServer.Replication.SnapshotGenerationAgent object or
asynchronously using the agent job. After the initial snapshot has been generated, it is transferred to and applied
at the Subscriber when the subscription is first synchronized. You will need to rerun the agent whenever the
existing snapshot no longer contains valid, up-to-date data. For more information, see Maintain Publications.
IMPORTANT
When possible, prompt users to enter security credentials at runtime. If you must store credentials, use the cryptographic
services provided by the Microsoft Windows .NET Framework.
To generate the initial snapshot for a snapshot or transactional publication by starting the Snapshot Agent job (asynchronous )
2. Create an instance of the TransPublication class. Set the Name and DatabaseName properties for the
publication, and set the ConnectionContext property to the connection created in step 1.
3. Call the LoadProperties method to load the remaining properties of the object. If this method returns
false, either the publication properties in step 2 were defined incorrectly or the publication does not exist.
4. If the value of SnapshotAgentExists is false, call CreateSnapshotAgent to create the snapshot agent job for
this publication.
5. Call the StartSnapshotGenerationAgentJob method to start the agent job that generates the snapshot for
this publication.
6. (Optional) When the value of SnapshotAvailable is true, the snapshot is available to Subscribers.
To generate the initial snapshot for a snapshot or transactional publication by running the Snapshot Agent (synchronous )
1. Create an instance of the Microsoft.SqlServer.Replication.SnapshotGenerationAgent class, and set the
following required properties:
Microsoft.SqlServer.Replication.SnapshotGenerationAgent.Publisher* - name of the Publisher
Microsoft.SqlServer.Replication.SnapshotGenerationAgent.PublisherDatabase* - name of the
publication database
Microsoft.SqlServer.Replication.SnapshotGenerationAgent.Publication* - name of the publication
Microsoft.SqlServer.Replication.SnapshotGenerationAgent.Distributor* - name of the Distributor
Microsoft.SqlServer.Replication.SnapshotGenerationAgent.PublisherSecurityMode* - a value of
Integrated to use Windows Authentication when connecting to the Publisher or a value of Standard
and values for Microsoft.SqlServer.Replication.SnapshotGenerationAgent.PublisherLogin* and
Microsoft.SqlServer.Replication.SnapshotGenerationAgent.PublisherPassword* to use SQL Server
Authentication when connecting to the Publisher. Windows Authentication is recommended.
Microsoft.SqlServer.Replication.SnapshotGenerationAgent.DistributorSecurityMode* - a value of
Integrated to use Windows Authentication when connecting to the Distributor or a value of
Standard and values for
Microsoft.SqlServer.Replication.SnapshotGenerationAgent.DistributorLogin* and
Microsoft.SqlServer.Replication.SnapshotGenerationAgent.DistributorPassword* to use SQL Server
Authentication when connecting to the Distributor. Windows Authentication is recommended.
2. Set a value of Transactional or Snapshot for
Microsoft.SqlServer.Replication.SnapshotGenerationAgent.ReplicationType*.
3. Call the Microsoft.SqlServer.Replication.SnapshotGenerationAgent.GenerateSnapshot* method.
To generate the initial snapshot for a merge publication by starting the Snapshot Agent job (asynchronous )
2. Create an instance of the MergePublication class. Set the Name and DatabaseName properties for the
publication, and set the ConnectionContext property to the connection created in step 1.
3. Call the LoadProperties method to load the remaining properties of the object. If this method returns
false, either the publication properties in step 2 were defined incorrectly or the publication does not exist.
this publication.
5. Call the StartSnapshotGenerationAgentJob method to start the agent job that generates the snapshot for
this publication.
6. (Optional) When the value of SnapshotAvailable is true, the snapshot is available to Subscribers.
To generate the initial snapshot for a merge publication by running the Snapshot Agent (synchronous )
Integrated to use Windows Authentication when connecting to the Publisher or a value of Standard
and values for Microsoft.SqlServer.Replication.SnapshotGenerationAgent.PublisherLogin* and
Microsoft.SqlServer.Replication.SnapshotGenerationAgent.PublisherPassword* to use SQL Server
Authentication when connecting to the Publisher. Windows Authentication is recommended.
Integrated to use Windows Authentication when connecting to the Distributor or a value of
Standard and values for
Microsoft.SqlServer.Replication.SnapshotGenerationAgent.DistributorLogin* and
Microsoft.SqlServer.Replication.SnapshotGenerationAgent.DistributorPassword* to use SQL Server
Authentication when connecting to the Distributor. Windows Authentication is recommended.
2. Set a value of Merge for Microsoft.SqlServer.Replication.SnapshotGenerationAgent.ReplicationType*.
Examples (RMO )
This example synchronously runs the Snapshot Agent to generate the initial snapshot for a transactional
publication.
// Set the Publisher, publication database, and publication names.
SnapshotGenerationAgent agent;
try
{
// Set the required properties for Snapshot Agent.
agent = new SnapshotGenerationAgent();
agent.Distributor = distributorName;
agent.DistributorSecurityMode = SecurityMode.Integrated;
agent.Publisher = publisherName;
agent.PublisherSecurityMode = SecurityMode.Integrated;
agent.Publication = publicationName;
agent.PublisherDatabase = publicationDbName;
agent.ReplicationType = ReplicationType.Transactional;
// Start the agent synchronously.

agent.GenerateSnapshot();
}
{
// Implement custom application error handling here.
"A snapshot could not be generated for the {0} publication."
, publicationName), ex);
}
' Set the Publisher, publication database, and publication names.

Dim agent As SnapshotGenerationAgent
Try
' Set the required properties for Snapshot Agent.
agent = New SnapshotGenerationAgent()
agent.Distributor = distributorName
agent.DistributorSecurityMode = SecurityMode.Integrated
agent.Publisher = publisherName
agent.PublisherSecurityMode = SecurityMode.Integrated
agent.Publication = publicationName
agent.PublisherDatabase = publicationDbName
agent.ReplicationType = ReplicationType.Transactional
' Start the agent synchronously.

agent.GenerateSnapshot()
' Implement custom application error handling here.
"A snapshot could not be generated for the {0} publication." _
, publicationName), ex)
End Try
This example asynchronously starts the agent job to generate the initial snapshot for a transactional publication.
// Create a connection to the Publisher using Windows Authentication.

ServerConnection conn;
conn = new ServerConnection(publisherName);
try
{
conn.Connect();
// Set the required properties for an existing publication.

{
// Start the Snapshot Agent job for the publication.
publication.StartSnapshotGenerationAgentJob();
}
else
{
"The {0} publication does not exist.", publicationName));
}
}
{
}
finally
{
conn.Disconnect();
}
' Create a connection to the Publisher using Windows Authentication.

Dim conn As ServerConnection
conn = New ServerConnection(publisherName)
Try
conn.Connect()
' Set the required properties for an existing publication.

' Start the Snapshot Agent job for the publication.
publication.StartSnapshotGenerationAgentJob()
Else
"The {0} publication does not exist.", publicationName))
End If
Finally
conn.Disconnect()
End Try
See Also
Use sqlcmd with Scripting Variables
Create a Snapshot for a Merge Publication with
Parameterized Filters
Warehouse
This topic describes how to create a snapshot for a merge publication with parameterized filters in SQL Server
2017 by using SQL Server Management Studio, Transact-SQL, or Replication Management Objects (RMO).
In This Topic
Before you begin:
Recommendations
To create a snapshot for a merge publication with parameterized filters, using:
Transact-SQL
Before You Begin

Recommendations
When generating a snapshot for a merge publication using parameterized filters, you must first generate a
standard (schema) snapshot that contains all of the published data and Subscriber metadata for the
subscription. For more information, see Create and Apply the Initial Snapshot. After you have created the
schema snapshot, you can generate the snapshot that contains the Subscriber-specific partition of the
published data.
If the filtering for one or more articles in the publication yields non-overlapping partitions that are unique
for each subscription, metadata is cleaned up whenever the Merge Agent runs. This means that the
partitioned snapshot expires more quickly. When using this option, you should consider allowing
Subscribers to initiate snapshot generation and delivery. For more information about filtering options, see
the "Setting 'partition options'" section of Snapshots for Merge Publications with Parameterized Filters.

Generate snapshots for partitions on the Data Partitions page of the Publication Properties - <Publication>
dialog box. For more information about accessing this dialog box, see View and Modify Publication Properties. You
can allow Subscribers to initiate snapshot generation and delivery and/or generate snapshots.
Before generating snapshots for one or more partitions, you must:
1. Create a merge publication with the New Publication Wizard, and specify one or more parameterized row
filters on the Add Filter page of the wizard. For more information, see Define and Modify a Parameterized
Row Filter for a Merge Article.
2. Generate a schema snapshot for the publication. By default, a schema snapshot is generated when you
complete the New Publication Wizard; you can also generate a schema snapshot from SQL Server
Management Studio.
To generate a schema snapshot
2. Expand the Replication folder, and then expand the Publications folder.
3. Right-click the publication for which you want to create a snapshot, and then click View Snapshot Agent
Status.
When the Snapshot Agent finishes generating the snapshot, a message will be displayed, such as "[100%] A
snapshot of 17 article(s) was generated."
To allow Subscribers to initiate snapshot generation and delivery
1. On the Data Partitions page of the Publication Properties - <Publication> dialog box, select
Automatically define a partition and generate a snapshot if needed when a new Subscriber tries
to synchronize.
2. Click OK.
To generate and refresh snapshots
1. On the Data Partitions page of the Publication Properties - <Publication> dialog box, click Add.
2. Enter a value for the HOST_NAME() and/or SUSER_SNAME() value associated with the partition for which
you want to create a snapshot.
3. Optionally specify a schedule for refreshing snapshots:
a. Select Schedule the Snapshot Agent for this partition to run at the following time(s)
b. Accept the default schedule for refreshing snapshots, or click Change to specify a different schedule.
4. Click OK, which returns you to the Publication Properties - <Publication> dialog box.
5. Select the partition in the property grid, and then click Generate the selected snapshots now.
6. Click OK.
Using Transact-SQL
Using stored procedures and the Snapshot Agent, you can perform the following:
Allow Subscribers to request snapshot generation and application the first time they synchronize.
Pre-generate snapshots for each partition.
Manually generate a snapshot for each Subscriber.
IMPORTANT
When possible, prompt users to enter security credentials at runtime. If you must store credentials in a script file, you
must secure the file to prevent unauthorized access.
To create a publication that allows Subscribers to initiate snapshot generation and delivery
1. At the Publisher on the publication database, execute sp_addmergepublication (Transact-SQL). Specify the
following parameters:
The name of the publication for @publication.
A value of true for @allow_subscriber_initiated_snapshot, which enables Subscribers to initiate
the snapshot process.
(Optional) The number of dynamic snapshot processes that can run concurrently for
@max_concurrent_dynamic_snapshots. If the maximum number of processes is running and a
Subscriber attempts to generate a snapshot, the process is placed in a queue. By default there is no
limit to the number of concurrent processes.
2. At the Publisher, execute sp_addpublication_snapshot (Transact-SQL). Specify the publication name used in
step 1 for @publication and the Microsoft Windows credentials under which the Replication Snapshot
Agent runs for @job_login and @password. If the agent will use SQL Server Authentication when
connecting to the Publisher, you must also specify a value of 0 for @publisher_security_mode and the
Microsoft SQL Server login information for @publisher_login and @publisher_password. This creates a
Snapshot Agent job for the publication. For more information about generating an initial snapshot and
defining a custom schedule for the Snapshot Agent, see Create and Apply the Initial Snapshot.
IMPORTANT
3. Execute sp_addmergearticle (Transact-SQL) to add articles to the publication. This stored procedure must be
executed once for each article in the publication. When using parameterized filters, you must specify a
parameterized row filter for one or more articles using the @subset_filterclause parameter. For more
information, see Define and Modify a Parameterized Row Filter for a Merge Article.
4. If other articles will be filtered based on the parameterized row filter, execute sp_addmergefilter (Transact-
SQL) to define the join or logical record relationships between articles. This stored procedure must be
executed once for each relationship being defined. For more information, see Define and Modify a Join Filter
Between Merge Articles.
5. When the Merge Agent requests the snapshot to initialize the Subscriber, the snapshot for the requesting
subscription's partition is automatically generated.
To create a publication and pre-generate or automatically refresh snapshots
1. Execute sp_addmergepublication (Transact-SQL) to create the publication. For more information, see Create
a Publication.
step 1 for @publication and the Windows credentials under which the Snapshot Agent runs for
@job_login and @password. If the agent will use SQL Server Authentication when connecting to the
Publisher, you must also specify a value of 0 for @publisher_security_mode and the SQL Server login
information for @publisher_login and @publisher_password. This creates a Snapshot Agent job for the
publication. For more information about generating an initial snapshot and defining a custom schedule for
the Snapshot Agent, see Create and Apply the Initial Snapshot.
IMPORTANT
parameterized row filter for one article using the @subset_filterclause parameter. For more information,
see Define and Modify a Parameterized Row Filter for a Merge Article.
5. At the Publisher on the publication database, execute sp_helpmergepublication (Transact-SQL), specifying
the value of @publication from step 1. Note the value of the snapshot_jobid in the result set.
6. Convert the value of the snapshot_jobid obtained in step 5 to uniqueidentifier.
7. At the Publisher on the msdb database, execute sp_start_job (Transact-SQL), specifying the converted value
obtained in step 6 for @job_id.
8. At the Publisher on the publication database, execute sp_addmergepartition (Transact-SQL). Specify the
name of the publication from step 1 for @publication and the value used to define the partition for
@suser_sname if SUSER_SNAME (Transact-SQL) is used in the filter clause or for @host_name if
HOST_NAME (Transact-SQL) is used in the filter clause.
9. At the publisher on the publication database, execute sp_adddynamicsnapshot_job (Transact-SQL). Specify
the name of the publication from step 1 for @publication, the value of @suser_sname or @host_name
from step 8, and a schedule for the job. This creates the job that generates the parameterized snapshot for
the specified partition. For more information, see Specify Synchronization Schedules.
NOTE
This job runs using the same Windows account as the initial snapshot job defined in step 2. To remove the
parameterized snapshot job and its related data partition, execute sp_dropdynamicsnapshot_job (Transact-SQL).
10. At the Publisher on the publication database, execute sp_helpmergepartition (Transact-SQL), specifying the
value of @publication from step 1 and the value of @suser_sname or @host_name from step 8. Note
the value of the dynamic_snapshot_jobid in the result set.
11. At the Distributor on the msdb database, execute sp_start_job (Transact-SQL), specifying the value obtained
in step 9 for @job_id. This starts the parameterized snapshot job for the partition.
12. Repeat steps 8-11 to generate a partitioned snapshot for each subscription.
To create a publication and manually create snapshots for each partition
1. Execute sp_addmergepublication (Transact-SQL) to create the publication. For more information, see Create
a Publication.
step 1 for @publication and the Windows credentials under which the Snapshot Agent runs for
@job_login and @password. If the agent will use SQL Server Authentication when connecting to the
Publisher, you must also specify a value of 0 for @publisher_security_mode and the SQL Server login
information for @publisher_login and @publisher_password. This creates a Snapshot Agent job for the
publication. For more information about generating an initial snapshot and defining a custom schedule for
the Snapshot Agent, see Create and Apply the Initial Snapshot.
IMPORTANT
parameterized row filter for at least one article using the @subset_filterclause parameter. For more
information, see Define and Modify a Parameterized Row Filter for a Merge Article.
5. Start the snapshot job or run the Replication Snapshot Agent from the command prompt to generate the
standard snapshot schema and other files. For more information, see Create and Apply the Initial Snapshot.
6. Run the Replication Snapshot Agent again from the command prompt to generate bulk copy (.bcp) files,
specifying the location of the partitioned snapshot for -DynamicSnapshotLocation and one or both of the
following properties that defines the partition:
-DynamicFilterHostName - the value if HOST_NAME (Transact-SQL) is used.
-DynamicFilterLogin - the value if SUSER_SNAME (Transact-SQL) is used.
7. Repeat step 6 to generate a partitioned snapshot for each subscription.
8. Run the Merge Agent for each subscription to apply the initial partitioned snapshot at the Subscribers,
specifying the following properties:
-Hostname - the value used to define the partition if the actual value of HOST_NAME is being
overridden.
-DynamicSnapshotLocation - the location of the dynamic snapshot for this partition.
NOTE
For more information about programming replication agents, see Replication Agent Executables Concepts.
This example creates a merge publication with parameterized filters where Subscribers initiate the snapshot
generation process. Values for @job_login and @job_password are passed in using scripting variables.
--Add a new merge publication.

DECLARE @publicationdb AS sysname;
DECLARE @table1 AS sysname;
DECLARE @filter AS sysname;
DECLARE @schema_hr AS sysname;
DECLARE @schema_sales AS sysname;
SET @publicationdb = N'AdventureWorks2012';

SET @publication = N'AdvWorksSalesPersonMerge';
SET @table1 = N'Employee';
SET @table2 = N'SalesPerson';
SET @filter = N'SalesPerson_Employee';
SET @schema_hr = N'HumanResources';
SET @schema_sales = N'Sales';
-- Enable AdventureWorks2012 for merge replication.

@dbname = @publicationdb,
@optname = N'merge publish',
@value = N'true';
-- Create new merge publication with Subscriber requested snapshot

-- and using the default agent schedule.
@description = N'Merge publication of AdventureWorks2012.',
@allow_subscriber_initiated_snapshot = N'true',
@publication_compatibility_level = N'90RTM';
-- Create a new snapshot job for the publication, using the default schedule.
-- Pass credentials at runtime using sqlcmd scripting variables.
@job_login = $(login),
@job_password = $(password);
-- Add an article for the Employee table,

-- which is horizontally partitioned using
-- a parameterized row filter.
EXEC sp_addmergearticle
@article = @table1,
@source_owner = @schema_hr,
@source_object = @table1,
@type = N'table',
@description = 'contains employee information',
@subset_filterclause = N'[LoginID] = HOST_NAME()';
-- Add an article for the SalesPerson table,

-- which is partitioned based on a join filter.
@article = @table2,
@source_owner = @schema_sales,
@type = N'table',
@description = 'contains salesperson information';
-- Add a join filter between the two articles.

EXEC sp_addmergefilter
@article = @table1,
@filtername = @filter,
@join_articlename = @table2,
@join_filterclause = N'[Employee].[BusinessEntityID] = [SalesPerson].[SalesPersonID]',
@join_unique_key = 1,
@filter_type = 1;
GO
-- Start the agent job to generate the full snapshot for the publication.
-- The filtered data snapshot is generated automatically the first time
-- the subscription is synchronized.
EXEC sp_startpublication_snapshot
GO
This example creates a publication using a parameterized filter where each Subscriber has its partition defined by
executing sp_addmergepartition and the filtered snapshot job created by executing sp_adddynamicsnapshot_job
passing the partitioning information. Values for @job_login and @job_password are passed in using scripting
variables.



@value = N'true';
-- Create new merge publication.

@allow_subscriber_initiated_snapshot = N'false';
-- Create a new snapshot job for the publication, using the

-- default schedule. Pass credentials at runtime using
-- sqlcmd scripting variables.
@job_password = $(password);

@article = @table1,
@type = N'table',

@article = @table2,
@type = N'table',
@description = 'contains customer information';

@article = @table1,
@filter_type = 1;
GO
-- Start the snapshot agent job.

EXEC sp_startpublication_snapshot
GO
PRINT '*** Waiting for the initial snapshot.';

GO
-- Create a temporary table to store the filtered data snapshot

-- job information.
CREATE TABLE #temp (id int,
job_name sysname,
job_id uniqueidentifier,
dynamic_filter_login sysname NULL,
dynamic_filter_hostname sysname NULL,
dynamic_snapshot_location nvarchar(255),
frequency_type int,
frequency_interval int,
frequency_subday_type int,
frequency_subday_interval int,
frequency_relative_interval int,
frequency_recurrence_factor int,
active_start_date int,
active_end_date int,
active_start_time int,
active_end_time int
)
-- Create each snapshot for a partition

-- The initial snapshot must already be generated.
DECLARE @jobname AS sysname
DECLARE @hostname AS sysname
SET @hostname = N'adventure-works\Fernando';
WHILE NOT EXISTS(SELECT * FROM sysmergepublications

WHERE [name] = @publication
AND snapshot_ready = 1)
BEGIN
WAITFOR DELAY '00:00:05'
END
-- Create a data partition by overriding HOST_NAME().

EXEC sp_addmergepartition
@host_name = @hostname;
-- Create the filtered data snapshot job, and use the returned
-- information to start the job.
EXEC sp_adddynamicsnapshot_job
@host_name = @hostname;
INSERT INTO #temp (id, job_name, job_id, dynamic_filter_login,

dynamic_filter_hostname, dynamic_snapshot_location,
frequency_type, frequency_interval, frequency_subday_type,
frequency_subday_interval, frequency_relative_interval,
frequency_recurrence_factor, active_start_date, active_end_date,
active_start_time,active_end_time)
EXEC sp_helpdynamicsnapshot_job;
SELECT @jobname = (SELECT DISTINCT job_name FROM #temp WHERE dynamic_filter_hostname = @hostname);
EXEC msdb..sp_start_job @job_name = @jobname;

DROP TABLE #temp;
GO
This example creates a publication using a parameterized filter where each Subscriber must have its data partition
and filtered snapshot job created by supplying the partitioning information. A Subscriber supplies partitioning
information using command-line parameters when manually running the replication agents. This example
assumes that a subscription to the publication has also been created.



@value = N'true';
-- Create new merge publication.

@allow_subscriber_initiated_snapshot = N'false';
-- Create a new snapshot job for the publication, using the

-- default schedule. Pass credentials at runtime using
-- sqlcmd scripting variables.

@article = @table1,
@type = N'table',

@article = @table2,
@type = N'table',
@description = 'contains customer information';

@article = @table1,
@filter_type = 1;
GO
REM Line breaks are added to improve readability.

REM In a batch file, commands must be made in a single line.
REM Run the Snapshot agent from the command line to generate the standard snapshot
REM schema and other files.
SET DistPub=%computername%
SET PubDB=AdventureWorks2012
SET PubName=AdvWorksSalesPersonMerge
"C:\Program Files\Microsoft SQL Server\120\COM\SNAPSHOT.EXE" -Publication %PubName%

-Publisher %DistPub% -Distributor %DistPub% -PublisherDB %PubDB% -ReplicationType 2
-OutputVerboseLevel 1 -DistributorSecurityMode 1
PAUSE
REM Run the Snapshot agent from the command line, this time to generate
REM the bulk copy (.bcp) data for each Subscriber partition.
SET DistPub=%computername%
SET PubDB=AdventureWorks2012
SET PubName=AdvWorksSalesPersonMerge
SET SnapshotDir=\\%DistPub%\repldata\unc\fernando
MD %SnapshotDir%
"C:\Program Files\Microsoft SQL Server\120\COM\SNAPSHOT.EXE" -Publication %PubName%

-Publisher %DistPub% -Distributor %DistPub% -PublisherDB %PubDB% -ReplicationType 2
-OutputVerboseLevel 1 -DistributorSecurityMode 1 -DynamicFilterHostName "adventure-works\Fernando"
-DynamicSnapshotLocation %SnapshotDir%
PAUSE
REM Run the Merge Agent for each subscription to apply the partitioned
REM snapshot for each Subscriber.
SET Publisher = %computername%
SET Subscriber = %computername%
SET PubDB = AdventureWorks2012
SET SubDB = AdventureWorks2012Replica
SET PubName = AdvWorksSalesPersonMerge
SET SnapshotDir=\\%DistPub%\repldata\unc\fernando
"C:\Program Files\Microsoft SQL Server\120\COM\REPLMERG.EXE" -Publisher %Publisher%

-Subscriber %Subscriber% -Distributor %Publisher% -PublisherDB %PubDB%
-SubscriberDB %SubDB% -Publication %PubName% -PublisherSecurityMode 1 -OutputVerboseLevel 3
-Output -SubscriberSecurityMode 1 -SubscriptionType 3 -DistributorSecurityMode 1
-Hostname "adventure-works\Fernando" -DynamicSnapshotLocation %SnapshotDir%
PAUSE

You can use Replication Management Objects (RMO) to generate partitioned snapshots programmatically in the
following ways:
Allow Subscribers to request snapshot generation and application the first time they synchronize.
Pre-generate snapshots for each partition.
Manually generate a snapshot for each Subscriber by running the Snapshot Agent.
NOTE
When filtering for an article yields non-overlapping partitions that are unique for each subscription (by specifying a value of
F:Microsoft.SqlServer.Replication.PartitionOptions.NonOverlappingSingleSubscription for
P:Microsoft.SqlServer.Replication.MergeArticle.PartitionOption when creating a merge article), metadata is cleaned up
whenever the Merge Agent runs. This means that the partitioned snapshot expires more quickly. When you use this option,
you should consider allowing Subscribers to request snapshot generation. For more information, see the section Using the
Appropriate Filtering Options in the topic Parameterized Row Filters.
IMPORTANT
When possible, prompt users to enter security credentials at runtime. If you must store credentials, use the cryptographic
services provided by the Microsoft Windows .NET Framework.
To create a publication that allows Subscribers to initiate snapshot generation and delivery
2. Create an instance of the ReplicationDatabase class for the publication database, set the ConnectionContext
property to the instance of ServerConnection from step 1, and call the LoadProperties method. If
LoadProperties returns false, confirm that the database exists.
3. If EnabledMergePublishing property is false, set it to true and call CommitPropertyChanges.
4. Create an instance of the MergePublication class, and set the following properties for this object:
The ServerConnection from step 1 for ConnectionContext.
The name of the published database for DatabaseName.
A name for the publication for Name.
The maximum number of dynamic snapshot jobs to run for MaxConcurrentDynamicSnapshots.
Because Subscriber initiated snapshot requests can occur at any time, this property limits the number
of Snapshot Agent jobs that can run simultaneously when multiple Subscribers request their
partitioned snapshot at the same time. When the maximum number of jobs are running, additional
partitioned snapshot requests are queued until one of the running jobs is completed.
Use the bitwise logical OR (| in Visual C# and Or in Visual Basic) operator to add the value
AllowSubscriberInitiatedSnapshot to Attributes.
The Login and Password fields of SnapshotGenerationAgentProcessSecurity to provide the
credentials for the Microsoft Windows account under which the Snapshot Agent job runs.
NOTE
Setting SnapshotGenerationAgentProcessSecurity is recommended when the publication is created by a
member of the sysadmin fixed server role. For more information, see Replication Agent Security Model.
5. Call the Create method to create the publication.
IMPORTANT
When configuring a Publisher with a remote Distributor, the values supplied for all properties, including
SnapshotGenerationAgentProcessSecurity, are sent to the Distributor as plain text. You should encrypt the
connection between the Publisher and its remote Distributor before calling the Create method. For more
information, see Enable Encrypted Connections to the Database Engine (SQL Server Configuration Manager).
6. Use the MergeArticle property to add articles to the publication. Specify the FilterClause property for at least
one article that defines the parameterized filter. (Optional) Create MergeJoinFilter objects that define join
filters between articles. For more information, see Define an Article.
7. If the value of SnapshotAgentExists is false, call CreateSnapshotAgent to create the initial Snapshot Agent
job for this publication.
8. Call the StartSnapshotGenerationAgentJob method of the MergePublication object created in step 4. This
starts the agent job that generates the initial snapshot. For more information about generating an initial
snapshot and defining a custom schedule for the Snapshot Agent, see Create and Apply the Initial Snapshot.
9. (Optional) Check for a value of true for the SnapshotAvailable property to determine when the initial
snapshot is ready for use.
10. When the Merge Agent for a Subscriber connects for the first time, a partitioned snapshot is generated
automatically.
To create a publication and pregenerate or automatically refresh snapshots
1. Use an instance of the MergePublication class to define a merge publication. For more information, see
Create a Publication.
2. Use the MergeArticle property to add articles to the publication. Specify the FilterClause property for at least
one article that defines the parameterized filter, and create any MergeJoinFilter objects that define join
this publication.
4. Call the StartSnapshotGenerationAgentJob method of the MergePublication object created in step 1. This
method starts the agent job that generates the initial snapshot. For more information on generating an
initial snapshot and defining a custom schedule for the Snapshot Agent, see Create and Apply the Initial
Snapshot.
5. Check for a value of true for the SnapshotAvailable property to determine when the initial snapshot is
ready for use.
6. Create an instance of the MergePartition class, and set the parameterized filtering criteria for the Subscriber
by using one or both of the following properties:
If the Subscriber's partition is defined by the result of SUSER_SNAME (Transact-SQL), use
DynamicFilterLogin.
If the Subscriber's partition is defined by the result of HOST_NAME (Transact-SQL) or an overload of
this function, use DynamicFilterHostName.
7. Create an instance of the MergeDynamicSnapshotJob class, and set the same property as in step 6.
8. Use the ReplicationAgentSchedule class to define a schedule for generating the filtered snapshot for the
Subscriber partition.
9. Using the instance of MergePublication from step 1, call AddMergePartition. Pass the MergePartition object
from step 6.
10. Using the instance of MergePublication from step 1, call the AddMergeDynamicSnapshotJob method. Pass
the MergeDynamicSnapshotJob object from step 7 and the ReplicationAgentSchedule object from step 8.
11. Call EnumMergeDynamicSnapshotJobs, and locate the MergeDynamicSnapshotJob object for the newly
added partitioned snapshot job in the returned array.
12. Get the Name property for the job.
14. Create an instance of the SQL Server Management Objects (SMO) Server class, passing the
15. Create an instance of the Job class, passing the JobServer property of the Server object from step 14 and
the job name from step 12.
16. Call the Start method to start the partitioned snapshot job.
17. Repeat steps 6-16 for each Subscriber.
To create a publication and manually create snapshots for each partition
1. Use an instance of the MergePublication class to define a merge publication. For more information, see
Create a Publication.
2. Use the MergeArticle property to add articles to the publication Specify the FilterClause property for at least
one article that defines the parameterized filter, and create any MergeJoinFilter objects that define join
3. Generate the initial snapshot. For more information, see Create and Apply the Initial Snapshot.
Integrated to used Windows Integrated Authentication or a value of Standard to use SQL Server
Authentication.
Integrated to used Windows Integrated Authentication or a value of Standard to use SQL Server
Authentication.
5. Set a value of Merge for Microsoft.SqlServer.Replication.SnapshotGenerationAgent.ReplicationType*.
6. Set one or more of the following properties to define the partitioning parameters:
If the Subscriber's partition is defined by the result of SUSER_SNAME (Transact-SQL), use
Microsoft.SqlServer.Replication.SnapshotGenerationAgent.DynamicFilterLogin*.
If the Subscriber's partition is defined by the result of HOST_NAME (Transact-SQL) or an overload of
this function, use
Microsoft.SqlServer.Replication.SnapshotGenerationAgent.DynamicFilterHostName*.
8. Repeat steps 4-7 for each Subscriber.
Examples (RMO )
This example creates a merge publication that allows Subscribers to requested snapshot generation.

// Create a connection to the Publisher.

try
{
conn.Connect();
// Enable the database for merge publication.

publicationDb = new ReplicationDatabase(publicationDbName, conn);
if (publicationDb.LoadProperties())
{
if (!publicationDb.EnabledMergePublishing)
{
publicationDb.EnabledMergePublishing = true;
}
}
else
{
// Do something here if the database does not exist.
"The {0} database does not exist on {1}.",
publicationDb, publisherName));
}
// Set the required properties for the merge publication.

// Enable precomputed partitions.

publication.PartitionGroupsOption = PartitionGroupsOption.True;
// Specify the Windows account under which the Snapshot Agent job runs.
// This account will be used for the local connection to the
// Distributor and all agent connections that use Windows Authentication.
publication.SnapshotGenerationAgentProcessSecurity.Login = winLogin;
publication.SnapshotGenerationAgentProcessSecurity.Password = winPassword;
// Explicitly set the security mode for the Publisher connection

// Windows Authentication (the default).
publication.SnapshotGenerationAgentPublisherSecurity.WindowsAuthentication = true;
// Enable Subscribers to request snapshot generation and filtering.

publication.Attributes |= PublicationAttributes.AllowSubscriberInitiatedSnapshot;
publication.Attributes |= PublicationAttributes.DynamicFilters;
// Enable pull and push subscriptions.

if (!publication.IsExistingObject)
{
// Create the merge publication.
publication.Create();
// Create a Snapshot Agent job for the publication.

publication.CreateSnapshotAgent();
}
else
{
"The {0} publication already exists.", publicationName));
}
}

{
"The publication {0} could not be created.", publicationName), ex);
}
finally
{
conn.Disconnect();
}


' Create a connection to the Publisher.

Try
conn.Connect()
' Enable the database for merge publication.

publicationDb = New ReplicationDatabase(publicationDbName, conn)
If publicationDb.LoadProperties() Then
If Not publicationDb.EnabledMergePublishing Then
publicationDb.EnabledMergePublishing = True
End If
Else
' Do something here if the database does not exist.
"The {0} database does not exist on {1}.", _
publicationDb, publisherName))
End If
' Set the required properties for the merge publication.

' Enable precomputed partitions.

publication.PartitionGroupsOption = PartitionGroupsOption.True
' Specify the Windows account under which the Snapshot Agent job runs.
' This account will be used for the local connection to the
' Distributor and all agent connections that use Windows Authentication.
publication.SnapshotGenerationAgentProcessSecurity.Login = winLogin
publication.SnapshotGenerationAgentProcessSecurity.Password = winPassword
' Explicitly set the security mode for the Publisher connection
' Windows Authentication (the default).
publication.SnapshotGenerationAgentPublisherSecurity.WindowsAuthentication = True
' Enable Subscribers to request snapshot generation and filtering.

publication.Attributes = publication.Attributes Or _
PublicationAttributes.AllowSubscriberInitiatedSnapshot
PublicationAttributes.DynamicFilters
' Enable pull and push subscriptions

PublicationAttributes.AllowPull
PublicationAttributes.AllowPush
If Not publication.IsExistingObject Then

' Create the merge publication.
publication.Create()
' Create a Snapshot Agent job for the publication.

publication.CreateSnapshotAgent()
Else
"The {0} publication already exists.", publicationName))
End If
"The publication {0} could not be created.", publicationName), ex)
Finally
conn.Disconnect()
End Try
This example manually creates the Subscriber partition and the filtered snapshot for a merge publication with
parameterized row filters.
// Define the server, database, and publication names

MergePartition partition;
MergeDynamicSnapshotJob snapshotAgentJob;
ReplicationAgentSchedule schedule;

// Create a connection to the Distributor to start the Snapshot Agent.

try
{
// Set the required properties for the publication.

// If we can't get the properties for this merge publication,

// then throw an application exception.
if (publication.LoadProperties() || publication.SnapshotAvailable)
{
// Set a weekly schedule for the filtered data snapshot.
schedule = new ReplicationAgentSchedule();
schedule.FrequencyType = ScheduleFrequencyType.Weekly;
schedule.FrequencyRecurrenceFactor = 1;
schedule.FrequencyInterval = Convert.ToInt32(0x001);
// Set the value of Hostname that defines the data partition.

partition = new MergePartition();
partition.DynamicFilterHostName = hostname;
snapshotAgentJob = new MergeDynamicSnapshotJob();
snapshotAgentJob.DynamicFilterHostName = hostname;
// Create the partition for the publication with the defined schedule.
publication.AddMergePartition(partition);
publication.AddMergePartition(partition);
publication.AddMergeDynamicSnapshotJob(snapshotAgentJob, schedule);
}
else
{
"Settings could not be retrieved for the publication, " +
" or the initial snapshot has not been generated. " +
"Ensure that the publication {0} exists on {1} and " +
"that the Snapshot Agent has run successfully.",
}
}
{
// Do error handling here.
throw new ApplicationException(string.Format(
"The partition for '{0}' in the {1} publication could not be created.",
hostname, publicationName), ex);
}
finally
{
if (distributorConn.IsOpen) distributorConn.Disconnect();
}
' Define the server, database, and publication names

Dim partition As MergePartition
Dim snapshotAgentJob As MergeDynamicSnapshotJob
Dim schedule As ReplicationAgentSchedule

' Create a connection to the Distributor to start the Snapshot Agent.

Try
' Set the required properties for the publication.

' If we can't get the properties for this merge publication,

' then throw an application exception.
If (publication.LoadProperties() Or publication.SnapshotAvailable) Then
' Set a weekly schedule for the filtered data snapshot.
schedule = New ReplicationAgentSchedule()
schedule.FrequencyType = ScheduleFrequencyType.Weekly
schedule.FrequencyRecurrenceFactor = 1
schedule.FrequencyInterval = Convert.ToInt32("0x001", 16)
' Set the value of Hostname that defines the data partition.
partition = New MergePartition()
partition.DynamicFilterHostName = hostname
snapshotAgentJob = New MergeDynamicSnapshotJob()
snapshotAgentJob.DynamicFilterHostName = hostname
' Create the partition for the publication with the defined schedule.
publication.AddMergePartition(partition)
publication.AddMergeDynamicSnapshotJob(snapshotAgentJob, schedule)
Else
"Settings could not be retrieved for the publication, " + _
" or the initial snapshot has not been generated. " + _
"Ensure that the publication {0} exists on {1} and " + _
"that the Snapshot Agent has run successfully.", _
End If
' Do error handling here.
"The partition for '{0}' in the {1} publication could not be created.", _
hostname, publicationName), ex)
Finally
If distributorConn.IsOpen Then
End If
End Try
This example manually starts the Snapshot Agent to generate the filtered data snapshot for a Subscriber to a
merge publication with parameterized row filters.

SnapshotGenerationAgent agent;
try
{
// Set the required properties for Snapshot Agent.
agent = new SnapshotGenerationAgent();
agent.Distributor = distributorName;
agent.Publisher = publisherName;
agent.Publication = publicationName;
agent.PublisherDatabase = publicationDbName;
agent.ReplicationType = ReplicationType.Merge;
// Specify the partition information to generate a

// filtered snapshot based on Hostname.
agent.DynamicFilterHostName = hostname;
// Start the agent synchronously.

agent.GenerateSnapshot();
}
{
}
Dim agent As SnapshotGenerationAgent
Try
' Set the required properties for Snapshot Agent.
agent = New SnapshotGenerationAgent()
agent.Distributor = distributorName
agent.Publisher = publisherName
agent.Publication = publicationName
agent.PublisherDatabase = publicationDbName
agent.ReplicationType = ReplicationType.Merge
' Specify the partition information to generate a

' filtered snapshot based on Hostname.
agent.DynamicFilterHostName = hostname
' Start the agent synchronously.

agent.GenerateSnapshot()
End Try
See Also
Snapshots for Merge Publications with Parameterized Filters
Enable Initialization with Backup for Transactional
Publications
Warehouse
To initialize a subscription to a transactional publication from a backup, enable the publication to allow
initialization from a backup, and then specify backup information when creating the subscription:
Enable the publication on the Subscription Options page of the Publication Properties - <Publication>
dialog box. For more information about accessing this dialog box, see View and Modify Publication
Properties.
Specify backup information with the stored procedure sp_addsubscription (Transact-SQL). For more
information about the parameters required by sp_addsubscription, see Initialize a Transactional
Subscription from a Backup (Replication Transact-SQL Programming).
To enable initialization with a backup
1. On the Subscription Options page of the Publication Properties - <Publication> dialog box, select a value
of True for the Allow initialization from backup files option.
See Also
Initialize a Transactional Subscription from a Backup
Warehouse
Although a subscription to a transactional publication is typically initialized with a snapshot, a subscription can be
initialized from a backup using replication stored procedures. For more information, see Initialize a Transactional
Subscription Without a Snapshot.
To initialize a transactional subscriber from a backup
1. For an existing publication, ensure that the publication supports the ability to initialize from backup by
executing sp_helppublication (Transact-SQL) at the Publisher on the publication database. Note the value of
allow_initialize_from_backup in the result set.
If the value is 1, the publication supports this functionality.
If the value is 0, execute sp_changepublication (Transact-SQL) at the Publisher on the publication
database. Specify a value of allow_initialize_from_backup for @property and a value of true for
@value.
2. For a new publication, execute sp_addpublication (Transact-SQL) at the Publisher on the publication
database. Specify a value of true for allow_initialize_from_backup. For more information, see Create a
Publication.
WARNING
To avoid missing subscriber data, when using sp_addpublication with
@allow_initialize_from_backup = N'true' , always use @immediate_sync = N'true' .
3. Create a backup of the publication database using the BACKUP (Transact-SQL) statement.
4. Restore the backup on the Subscriber using the RESTORE (Transact-SQL) statement.
5. At the Publisher on the publication database, execute the stored procedure sp_addsubscription (Transact-
SQL). Specify the following parameters:
@sync_type - a value of initialize with backup.
@backupdevicetype - the type of backup device: logical (default), disk, or tape.
@backupdevicename - the logical or physical backup device to use for the restore.
For a logical device, specify the name of the backup device specified when sp_addumpdevice was
used to create the device.
For a physical device, specify a complete path and file name, such as
DISK = 'C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\BACKUP\Mybackup.dat' or
TAPE = '\\.\TAPE0' .
(Optional) @password - a password that was provided when the backup set was created.
(Optional) @mediapassword - a password that was provided when the media set was formatted.
(Optional) @fileidhint - identifier for the backup set to be restored. For example, specifying 1
indicates the first backup set on the backup medium and 2 indicates the second backup set.
(Optional for tape devices) @unload - specify a value of 1 (default) if the tape should be unloaded
from the drive after the restore is complete and 0 if it should not be unloaded.
6. (Optional) For a pull subscription, execute sp_addpullsubscription (Transact-SQL) and
sp_addpullsubscription_agent (Transact-SQL) at the Subscriber on the subscription database. For more
7. (Optional) Start the Distribution Agent. For more information, see Synchronize a Pull Subscription or
Synchronize a Push Subscription.
See Also
Copy Databases with Backup and Restore
Back Up and Restore of SQL Server Databases
Warehouse
This topic describes how to initialize a subscription manually in SQL Server 2017 by using SQL Server
Management Studio or Transact-SQL. While the initial snapshot is normally used to initialize a subscription,
subscriptions to publications can be initialized without using a snapshot, provided that the schema and initial data
are already present at the subscriber.
Before You Begin

Limitations and Restrictions
If there is activity on a database published using transactional replication between the time data and schema
are copied to the Subscriber and the time at which the subscription is manually initialized, changes resulting
from this activity might not be replicated to the Subscriber.

Initialize a subscription to a publication manually by copying the schema (and typically data) to the subscription
database. The schema and data should match the publication database. Then specify that the subscription does not
require schema and data on the Initialize Subscriptions page of the New Subscription Wizard. For more
information about accessing this wizard, see Initialize a Transactional Subscription Without a Snapshot and Create
a Pull Subscription.
When you synchronize the subscription for the first time, the objects and metadata required by replication are
copied to the subscription database.
To initialize a subscription to a publication manually
1. Ensure that the schema and data are copied to the subscription database.
2. Clear the Initialize check box on the Initialize Subscriptions page of the New Subscription Wizard. Do
this for each subscription that requires only replication objects and metadata to be copied.
Using Transact-SQL
Subscriptions can be initialized manually using replication stored procedures.
To manually initialize a pull subscription to a transactional publication
1. Ensure that the schema and data exist on the subscription database. For more information, see Initialize a
Transactional Subscription Without a Snapshot.
2. At the Publisher on the publication database, execute sp_addsubscription. Specify @publication,
@subscriber, the name of the database at the Subscriber containing the published data for
@destination_db, a value of pull for @subscription_type, and a value of replication support only for
@sync_type. For more information, see Create a Pull Subscription.
3. At the Subscriber, execute sp_addpullsubscription. For updating subscriptions, see Create an Updatable
Subscription to a Transactional Publication.
4. At the Subscriber, execute sp_addpullsubscription_agent. For more information, see Create a Pull
Subscription.
5. Start the Distribution Agent to transfer replication objects and download the latest changes from the
Publisher. For more information, see Synchronize a Pull Subscription.
To manually initialize a push subscription to a transactional publication
1. Ensure that the schema and data exist on the subscription database. For more information, see Initialize a
2. At the Publisher on the publication database, execute sp_addsubscription. Specify the name of the database
at the Subscriber containing the published data for @destination_db, a value of push for
@subscription_type, and a value of replication support only for @sync_type. For updating
subscriptions, see Create an Updatable Subscription to a Transactional Publication.
3. At the Publisher on the publication database, execute sp_addpushsubscription_agent. For more information,
see Create a Push Subscription.
4. Start the Distribution Agent to transfer replication objects and download the latest changes from the
Publisher. For more information, see Synchronize a Push Subscription.
To manually initialize a pull subscription to a merge publication
1. Ensure that the schema and data exist on the subscription database. This can be done by restoring a backup
of the publication database at the Subscriber.
2. At the Publisher, execute sp_addmergesubscription. Specify @publication, @subscriber, @subscriber_db,
and a value of pull for @subscription_type. This registers the pull subscription.
3. At the Subscriber on the database containing the published data, execute sp_addmergepullsubscription.
Specify a value of none for @sync_type.
4. At the Subscriber, execute sp_addmergepullsubscription_agent. For more information, see Create a Pull
Subscription.
5. Start the Merge Agent to transfer replication objects and download the latest changes from the Publisher.
For more information, see Synchronize a Pull Subscription.
To manually initialize a push subscription to a merge publication
1. Ensure that the schema and data exist on the subscription database. This can be done by restoring a backup
of the publication database at the Subscriber.
2. At the Publisher on the publication database, execute sp_addmergesubscription. Specify the name of the
database at the Subscriber containing the published data for @subscriber_db, a value of push for
@subscription_type, and a value of none for @sync_type.
3. At the Publisher on the publication database, execute sp_addmergepushsubscription_agent. For more
4. Start the Merge Agent to transfer replication objects and download the latest changes from the Publisher.
For more information, see Synchronize a Push Subscription.
See Also
Data Warehouse
This topic describes how to synchronize a pull subscription in SQL Server 2017 by using SQL Server
Management Studio, replication agents, or Replication Management Objects (RMO).
In This Topic
To synchronize a pull subscription, using:
Replication Agents

Merge Agent (for merge replication). Agents can run continuously, run on demand, or run on a schedule. For
more information about specifying synchronization schedules, see Specify Synchronization Schedules.
Synchronize a subscription on demand from the Local Subscriptions folder in SQL Server Management
Studio.
To synchronize a pull subscription on demand in Management Studio
3. Right-click the subscription you want to synchronize, and then click View Synchronization Status.
4. In the View Synchronization Status - <Subscriber>:<SubscriptionDatabase> dialog box, click
Start. When synchronization is complete, the message Synchronization completed is displayed.
5. Click Close.
Replication Agents
Pull subscriptions can be synchronized programmatically and on-demand by invoking the appropriate
replication agent executable file from the command prompt. The replication agent executable file that is
invoked will depend on the type of publication to which the pull subscription belongs. For more information,
see Replication Agents.
NOTE
Replication agents connect to the local server using the Windows Authentication credentials of the user who started the
agent from the command prompt. These Windows credentials are also used when connecting to remote servers using
Windows Integrated Authentication.
To start the distribution agent from the command prompt or from a batch file
1. From the command prompt or in a batch file, start the Replication Distribution Agent by running
distrib.exe, specifying the following command-line arguments:
-Publisher
-PublisherDB
-Distributor
-Subscriber
-SubscriberDB
-SubscriberSecurityMode = 1
-SubscriptionType = 1
-DistributorLogin
-PublisherLogin
-PublisherPassword
-SubscriberLogin
-SubscriberPassword
To start the merge agent from the command prompt or from a batch file
1. From the command prompt or in a batch file, start the Replication Merge Agent by running
replmerg.exe, specifying the following command-line arguments:
-Publisher
-PublisherDB
-Publication
-Distributor
-Subscriber
-SubscriberDB
-DistributorLogin
-PublisherLogin
-PublisherPassword
-SubscriberLogin
-SubscriberPassword
Examples (Replication Agents)
The following example starts the Distribution Agent to synchronize a pull subscription. All connections are
made using Windows Authentication.
-- Declare the variables.

SET Publisher=%instancename%
SET Subscriber=%instancename%
SET PublicationDB=AdventureWorks
SET SubscriptionDB=AdventureWorksReplica
SET Publication=AdvWorksProductsTran
-- Start the Distribution Agent.

-- The following command must be supplied without line breaks.
"C:\Program Files\Microsoft SQL Server\100\COM\DISTRIB.EXE" -Subscriber %Subscriber%
-SubscriberDB %SubscriptionDB% -SubscriberSecurityMode 1 -Publication %Publication%
-Publisher %Publisher% -PublisherDB %PublicationDB% -Distributor %Publisher%
-DistributorSecurityMode 1 -Continuous -SubscriptionType 1;
The following example starts the Merge Agent to synchronize a pull subscription. All connections are made
-- Declare the variables.

SET PublicationDB=AdventureWorks
SET SubscriptionDB=AdventureWorksReplica
--Start the Merge Agent with concurrent upload and download processes.
-- The following command must be supplied without line breaks.
"C:\Program Files\Microsoft SQL Server\100\COM\REPLMERG.EXE" -Publication %Publication%
-Publisher %Publisher% -Subscriber %Subscriber% -Distributor %Publisher%
-PublisherDB %PublicationDB% -SubscriberDB %SubscriptionDB% -PublisherSecurityMode 1
-OutputVerboseLevel 2 -SubscriberSecurityMode 1 -SubscriptionType 1 -DistributorSecurityMode 1
-Validate 3 -ParallelUploadDownload 1 ;

You can synchronize pull subscriptions programmatically by using Replication Management Objects (RMO)
and managed code access to replication agent functionalities. The classes you use to synchronize a pull
subscription depend on the type of publication to which the subscription belongs.
NOTE
If you want to start a synchronization that runs autonomously without affecting your application, start the agent
asynchronously. However, if you want to monitor the outcome of the synchronization and receive callbacks from the
agent during the synchronization process (for example, to display a progress bar), you should start the agent
synchronously. For Microsoft SQL Server 2005 Express Edition Subscribers, you must start the agent synchronously.
To synchronize a pull subscription to a snapshot or transactional publication

2. Create an instance of the TransPullSubscription class, and set the following properties:
The subscription database name for DatabaseName.
The name of the publication to which the subscription belongs for PublicationName.
The name of the publication database for PublicationDBName.
The name of the Publisher for PublisherName.
The connection created in step 1 for ConnectionContext.
3. Call the LoadProperties method to get the remaining subscription properties. If this method returns
false, verify that the subscription exists.
4. Start the Distribution Agent at the Subscriber in one of the following ways:
Call the SynchronizeWithJob method on the instance of TransPullSubscription from step 2. This
method starts the Distribution Agent asynchronously, and control immediately returns to your
application while the agent job is running. You cannot call this method for SQL Server 2005
Express Edition Subscribers or if the subscription was created with a value of false for
CreateSyncAgentByDefault (the default).
Get an instance of the TransSynchronizationAgent class from the SynchronizationAgent property,
and call the Synchronize method. This method starts the agent synchronously, and control
remains with the running agent job. During synchronous execution, you can handle the Status
event while the agent is running.
NOTE
If you specified a value of false for CreateSyncAgentByDefault (the default) when you created the pull
subscription, you also need to specify Distributor, DistributorSecurityMode, and optionally
DistributorLogin and DistributorPassword because the agent job related metadata for the subscription is
not available in MSsubscription_properties.
To synchronize a pull subscription to a merge publication

2. Create an instance of the MergePullSubscription class, and set the following properties:
The subscription database name for DatabaseName.
The name of the published database for PublicationDBName.
The name of the Publisher for PublisherName.
4. Start the Merge Agent at the Subscriber in one of the following ways:
Call the SynchronizeWithJob method on the instance of MergePullSubscription from step 2. This
method starts the Merge Agent asynchronously, and control immediately returns to your
application while the agent job is running. You cannot call this method for SQL Server 2005
Express Edition Subscribers or if the subscription was created with a value of false for
CreateSyncAgentByDefault (the default).
Obtain an instance of the MergeSynchronizationAgent class from the SynchronizationAgent
property, and call the Synchronize method. This method starts the Merge Agent synchronously,
and control remains with the running agent job. During synchronous execution, you can handle
the Status event while the agent is running.
NOTE
If you specified a value of false for CreateSyncAgentByDefault (the default) when you created the pull
subscription, you also need to specify Distributor, DistributorSecurityMode, PublisherSecurityMode,
HostName, SubscriptionType, ExchangeType, and optionally DistributorLogin, DistributorPassword,
PublisherLogin, and PublisherPassword because the agent job related metadata for the subscription is
not available in MSsubscription_properties.
Examples (RMO )
This example synchronizes a pull subscription to a transactional publication, where the agent is started
asynchronously using the agent job.
// Define server, publication, and database names.
String subscriberName = subscriberInstance;
String publisherName = publisherInstance;
String publicationName = "AdvWorksProductTran";
String publicationDbName = "AdventureWorks";
String subscriptionDbName = "AdventureWorksReplica";
// Create a connection to the Subscriber.

try
{
conn.Connect();
// Define subscription properties.

// If the pull subscription and the job exists, start the agent job.
if (subscription.LoadProperties() && subscription.AgentJobId != null)
{
subscription.SynchronizeWithJob();
}
else
{
// Do something here if the subscription does not exist.
"A subscription to '{0}' does not exists on {1}",
}
}
{
// Do appropriate error handling here.
throw new ApplicationException("The subscription could not be synchronized.", ex);
}
finally
{
conn.Disconnect();
}
' Define server, publication, and database names.
' Create a connection to the Subscriber.

Try
conn.Connect()
' Define subscription properties.

' If the pull subscription and the job exists, start the agent job.
If subscription.LoadProperties() And Not subscription.AgentJobId Is Nothing Then
subscription.SynchronizeWithJob()
Else
' Do something here if the subscription does not exist.
"A subscription to '{0}' does not exists on {1}", _
End If
' Do appropriate error handling here.
Throw New ApplicationException("The subscription could not be synchronized.", ex)
Finally
conn.Disconnect()
End Try
This example synchronizes a pull subscription to a transactional publication, where the agent is started
synchronously.
// Define the server, publication, and database names.

try
{
conn.Connect();

// If the pull subscription exists, then start the synchronization.

if (subscription.LoadProperties())
{
// Check that we have enough metadata to start the agent.
if (subscription.PublisherSecurity != null)
{
// Synchronously start the Distribution Agent for the subscription.
subscription.SynchronizationAgent.Synchronize();
}
else
{
throw new ApplicationException("There is insufficent metadata to " +
"synchronize the subscription. Recreate the subscription with " +
"the agent job or supply the required agent properties at run time.");
}
}
else
{
// Do something here if the pull subscription does not exist.
"A subscription to '{0}' does not exist on {1}",
}
}
{
throw new ApplicationException("The subscription could not be " +
"synchronized. Verify that the subscription has " +
"been defined correctly.", ex);
}
finally
{
conn.Disconnect();
}
' Define the server, publication, and database names.

Try
conn.Connect()

' If the pull subscription exists, then start the synchronization.

If subscription.LoadProperties() Then
' Check that we have enough metadata to start the agent.
If Not subscription.PublisherSecurity Is Nothing Then
' Write agent output to a log file.

subscription.SynchronizationAgent.Output = "distagent.log"
subscription.SynchronizationAgent.OutputVerboseLevel = 2
' Synchronously start the Distribution Agent for the subscription.

subscription.SynchronizationAgent.Synchronize()
Else
Throw New ApplicationException("There is insufficent metadata to " + _
"synchronize the subscription. Recreate the subscription with " + _
"the agent job or supply the required agent properties at run time.")
End If
Else
' Do something here if the pull subscription does not exist.
"A subscription to '{0}' does not exist on {1}", _
End If
Throw New ApplicationException("The subscription could not be " + _
"synchronized. Verify that the subscription has " + _
"been defined correctly.", ex)
Finally
conn.Disconnect()
End Try
This example synchronizes a pull subscription to a merge publication, where the agent is started
String publicationName = "AdvWorksSalesOrdersMerge";
String publicationDbName = "AdventureWorks";
String subscriptionDbName = "AdventureWorksReplica";

try
{
conn.Connect();

// If the pull subscription and the job exists, start the agent job.
{
}
else
{
}
}
{
}
finally
{
conn.Disconnect();
}

Try
conn.Connect()

' If the pull subscription and the job exists, start the agent job.
Else
End If
Finally
conn.Disconnect()
End Try
This example synchronizes a pull subscription to a merge publication, where the agent is started
synchronously.

try
{
conn.Connect();


{
if (subscription.PublisherSecurity != null || subscription.DistributorSecurity != null)
{
// Synchronously start the Merge Agent for the subscription.
}
else
{
}
}
else
{
}
}
{
}
finally
{
conn.Disconnect();
}

Try
conn.Connect()


If Not subscription.PublisherSecurity Is Nothing Or subscription.DistributorSecurity Is Nothing
Then
' Output agent messages to the console.

subscription.SynchronizationAgent.Output = ""
' Synchronously start the Merge Agent for the subscription.

Else
End If
Else
End If
Finally
conn.Disconnect()
End Try
This example synchronizes a pull subscription to a merge publication using Web synchronization. The
subscription was created without the agent job and related subscription metadata, so the agent must be started
synchronously and additional subscription information is supplied.

string distributorName = distributorInstance;
string webSyncUrl = "https://" + publisherInstance + "/SalesOrders/replisapi.dll";

MergeSynchronizationAgent agent;
try
{
conn.Connect();


{
// Get the agent for the subscription.
agent = subscription.SynchronizationAgent;

if (agent.PublisherSecurityMode == null)
{
// Set the required properties that could not be returned
// from the MSsubscription_properties table.
agent.Distributor = publisherName;
agent.HostName = hostname;
// Set optional Web synchronization properties.

agent.UseWebSynchronization = true;
agent.InternetUrl = webSyncUrl;
agent.InternetSecurityMode = SecurityMode.Standard;
agent.InternetLogin = winLogin;
agent.InternetPassword = winPassword;
}
// Enable agent output to the console.
agent.OutputVerboseLevel = 1;
agent.Output = "";

agent.Synchronize();
}
else
{
}
}
{
}
finally
finally
{
conn.Disconnect();
}

Dim webSyncUrl As String = "https://" + publisherInstance + "/SalesOrders/replisapi.dll"


Dim agent As MergeSynchronizationAgent
Try
conn.Connect()


' Get the agent for the subscription.
agent = subscription.SynchronizationAgent

If agent.PublisherSecurityMode = Nothing Then
' Set the required properties that could not be returned
' from the MSsubscription_properties table.
agent.Distributor = publisherInstance
agent.HostName = hostname
' Set optional Web synchronization properties.

agent.UseWebSynchronization = True
agent.InternetUrl = webSyncUrl
agent.InternetSecurityMode = SecurityMode.Standard
agent.InternetLogin = winLogin
agent.InternetPassword = winPassword
End If
' Enable agent logging to the console.

agent.OutputVerboseLevel = 1
agent.Output = ""

agent.Synchronize()
Else
End If
Finally
conn.Disconnect()
End Try
See Also
Synchronize Data
Data Warehouse
This topic describes how to synchronize a push subscription in SQL Server 2017 by using SQL Server
Management Studio, replication agents, or Replication Management Objects (RMO).
In This Topic
To synchronize a push subscription, using:
Replication Agents

Merge Agent (for merge replication). Agents can run continuously, run on demand, or run on a schedule. For
more information about specifying synchronization schedules, see Specify Synchronization Schedules.
Synchronize a subscription on demand from the Local Publications and Local Subscriptions folders in
Microsoft SQL Server Management Studio and the All Subscriptions tab in Replication Monitor. Subscriptions
to Oracle publications cannot be synchronized on demand from the Subscriber. For information about starting
Replication Monitor, see Start the Replication Monitor.
To synchronize a push subscription on demand in Management Studio (at the Publisher)
3. Expand the publication for which you want to synchronize subscriptions.
6. Click Close.
To synchronize a push subscription on demand in Management Studio (at the Subscriber)
4. A message is displayed about establishing a connection to the Distributor. Click OK.
6. Click Close.
To synchronize a push subscription on demand in Replication Monitor
1. In Replication Monitor, expand a Publisher group in the left pane, expand a Publisher, and then click a
publication.
3. Right-click the subscription you want to synchronize, and then click Start Synchronizing.
4. To view synchronization progress, right-click the subscription, and then click View Details.
Using Replication Agents

Push subscriptions can be synchronized programmatically and on-demand by invoking the appropriate
replication agent executable file from the command prompt. The replication agent executable file that is
invoked will depend on the type of publication to which the push subscription belongs.
To start the Distribution Agent to synchronize a push subscription to a transactional publication
1. From the command prompt or in a batch file at the Distributor, execute distrib.exe. Specify the
following command-line arguments:
-Publisher
-PublisherDB
-Distributor
-Subscriber
-SubscriberDB
-DistributorLogin
-PublisherLogin
-PublisherPassword
-SubscriberLogin
-SubscriberPassword
IMPORTANT
When possible, use Windows Authentication.
To start the Merge Agent to synchronize a push subscription to a merge publication

1. From the command prompt or in a batch file at the Distributor, execute replmerg.exe. Specify the
following command-line arguments:
-Publisher
-PublisherDB
-Publication
-Distributor
-Subscriber
-SubscriberDB
-DistributorLogin
-PublisherLogin
-PublisherPassword
-SubscriberLogin
-SubscriberPassword
IMPORTANT
When possible, use Windows Authentication.
Examples (Replication Agents)

The following example starts the Distribution Agent to synchronize a push subscription.
REM -- Declare the variables.

SET SubscriptionDB=AdventureWorks2012Replica
SET Publication=AdvWorksProductsTran
REM -- Start the Distribution Agent with four subscription streams.

REM -- The following command must be supplied without line breaks.
"C:\Program Files\Microsoft SQL Server\120\COM\DISTRIB.EXE" -Subscriber %Subscriber%
-SubscriberDB %SubscriptionDB% -SubscriberSecurityMode 1 -Publication %Publication%
-Publisher %Publisher% -PublisherDB %PublicationDB% -Distributor %Publisher%
-DistributorSecurityMode 1 -Continuous -SubscriptionType 0 -SubscriptionStreams 4
The following example starts the Merge Agent to synchronize a push subscription.
REM -- Declare the variables.
SET SubscriptionDB=AdventureWorks2012Replica
REM -- Start the Merge Agent.

REM -- The following command must be supplied without line breaks.
"C:\Program Files\Microsoft SQL Server\120\COM\REPLMERG.EXE" -Publisher %Publisher%
-Subscriber %Subscriber% -Distributor %Publisher% -PublisherDB %PublicationDB%
-SubscriberDB %SubscriptionDB% -Publication %Publication% -PublisherSecurityMode 1
-OutputVerboseLevel 3 -Output -SubscriberSecurityMode 1 -SubscriptionType 0
-DistributorSecurityMode 1

You can synchronize push subscriptions programmatically by using Replication Management Objects (RMO)
and managed code access to replication agent functionalities. The classes that you use to synchronize a push
subscription depend on the type of publication to which the subscription belongs.
NOTE
If you want to start a synchronization that runs autonomously without affecting your application, start the agent
asynchronously. However, if you want to monitor the outcome of the synchronization and receive callbacks from the
agent during the synchronization process (for example, if you want to display a progress bar), you should start the agent
synchronously. For Microsoft SQL Server 2005 Express Edition Subscribers, you must start the agent synchronously.
To synchronize a push subscription to a snapshot or transactional publication

2. Create an instance of the TransSubscription class and set the following properties:
The publication database name for DatabaseName.
The name of the subscription database for SubscriptionDBName.
The name of the Subscriber for SubscriberName.
4. Start the Distribution Agent at the Distributor in one of the following ways:
Call the SynchronizeWithJob method on the instance of TransSubscription from step 2. This
method starts the Distribution Agent asynchronously, and control immediately returns to your
application while the agent job is running. You cannot call this method if the subscription was
created with a value of false for CreateSyncAgentByDefault.
Obtain an instance of the TransSynchronizationAgent class from the SynchronizationAgent
property, and call the Synchronize method. This method starts the agent synchronously, and
control remains with the running agent job. During synchronous execution you can handle the
Status event while the agent is running.
To synchronize a push subscription to a merge publication
2. Create an instance of the MergeSubscription class, and set the following properties:
The publication database name for DatabaseName.
The name of the subscription database for SubscriptionDBName.
The name of the Subscriber for SubscriberName.
4. Start the Merge Agent at the Distributor in one of the following ways:
Call the SynchronizeWithJob method on the instance of MergeSubscription from step 2. This
method starts the Merge Agent asynchronously, and control immediately returns to your
application while the agent job is running. You cannot call this method if the subscription was
created with a value of false for CreateSyncAgentByDefault.
Obtain an instance of the MergeSynchronizationAgent class from the SynchronizationAgent
property, and call the Synchronize method. This method starts the Merge Agent synchronously,
and control remains with the running agent job. During synchronous execution, you can handle
the Status event while the agent is running.
Examples (RMO )
This example synchronizes a push subscription to a transactional publication, where the agent is started
/// Create a connection to the Publisher.

try
{
conn.Connect();
// Instantiate the push subscription.

// If the push subscription and the job exists, start the agent job.
{
// Start the Distribution Agent asynchronously.
}
else
{
}
}
{
}
finally
{
conn.Disconnect();
}

Try
conn.Connect()
' Instantiate the push subscription.

' If the push subscription and the job exists, start the agent job.
' Start the Distribution Agent asynchronously.
Else
End If
Finally
conn.Disconnect()
End Try
This example synchronizes a push subscription to a transactional publication, where the agent is started
synchronously.

try
{
conn.Connect();

// If the push subscription exists, start the synchronization.

{
if (subscription.SubscriberSecurity != null)
{
// Synchronously start the Distribution Agent for the subscription.
}
else
{
}
}
else
{
// Do something here if the push subscription does not exist.
"The subscription to '{0}' does not exist on {1}",
}
}
{
}
finally
{
conn.Disconnect();
}

Try
conn.Connect()

' If the push subscription exists, start the synchronization.

If Not subscription.SubscriberSecurity Is Nothing Then
' Synchronously start the Distribution Agent for the subscription.

Else
End If
Else
' Do something here if the push subscription does not exist.
"The subscription to '{0}' does not exist on {1}", _
End If
Finally
conn.Disconnect()
End Try
This example synchronizes a push subscription to a merge publication, where the agent is started

try
{
conn.Connect();
// Define push subscription.

// If the push subscription and the job exists, start the agent job.
{
// Start the Merge Agent asynchronously.
}
else
{
}
}
{
}
finally
{
conn.Disconnect();
}

Try
conn.Connect()
' Define push subscription.

' If the push subscription and the job exists, start the agent job.
' Start the Merge Agent asynchronously.
Else
End If
Finally
conn.Disconnect()
End Try
This example synchronizes a push subscription to a merge publication, where the agent is started
synchronously.

try
{
// Connect to the Publisher
conn.Connect();
// Define the subscription.

// If the push subscription exists, start the synchronization.

{
if (subscription.SubscriberSecurity != null)
{
}
else
{
}
}
else
{
// Do something here if the push subscription does not exist.
"The subscription to '{0}' does not exist on {1}",
}
}
{
}
finally
{
conn.Disconnect();
}

Try
' Connect to the Publisher
conn.Connect()
' Define the subscription.

' If the push subscription exists, start the synchronization.

If Not subscription.SubscriberSecurity Is Nothing Then
' Log agent messages to an output file.
subscription.SynchronizationAgent.Output = "mergeagent.log"
Else
End If
Else
' Do something here if the push subscription does not exist.
"The subscription to '{0}' does not exist on {1}", _
End If
Finally
conn.Disconnect()
End Try
See Also
Synchronize Data
Warehouse
This topic describes how to reinitialize a subscription in SQL Server 2017 by using SQL Server Management
Studio, Transact-SQL, or Replication Management Objects (RMO). Individual subscriptions can be marked for
reinitialization so that a new snapshot is applied during the next synchronization.
In This Topic
To reinitialize a subscription, using:
Transact-SQL

Reinitializing a subscription is a two-part process:
1. A single subscription or all subscriptions to a publication are marked for reinitialization. Mark subscriptions
for reinitialization in the Reinitialize Subscription(s) dialog box, which is available from the Local
Publications folder and the Local Subscriptions folder in Microsoft SQL Server Management Studio. You
can also mark subscriptions from the All Subscriptions tab and the publications node in Replication
Monitor. For information about starting Replication Monitor, see Start the Replication Monitor. When you
mark a subscription for reinitialization, you have the following options:
Use the current snapshot
Select to apply the current snapshot to the Subscriber the next time the Distribution Agent or Merge Agent
runs. If there is no valid snapshot available, this option cannot be selected.
Use a new snapshot
Select to reinitialize the subscription with a new snapshot. The snapshot can be applied to the Subscriber
only after it has been generated by the Snapshot Agent. If the Snapshot Agent is set to run on a schedule,
the subscription is not reinitialized until after the next scheduled Snapshot Agent run. Select Generate the
new snapshot now to start the Snapshot Agent immediately.
Upload unsynchronized changes before reinitialization
Merge replication only. Select to upload any pending changes from the subscription database before the
data at the Subscriber is overwritten with a snapshot.
If you add, drop, or change a parameterized filter, pending changes at the Subscriber cannot be uploaded to
the Publisher during reinitialization. If you want to upload pending changes, synchronize all subscriptions
before changing the filter.
2. A subscription is reinitialized the next time it is synchronized: the Distribution Agent (for transactional
replication) or Merge Agent (for merge replication) applies the most recent snapshot to each Subscriber
that has a subscription marked for reinitialization. For more information about synchronizing subscriptions,
see Synchronize a Push Subscription and Synchronize a Pull Subscription.
To mark a single push or pull subscription for reinitialization in Management Studio (at the Publisher)
3. Expand the publication that has the subscription you want to reinitialize.
4. Right-click the subscription, and then click Reinitialize.
5. In the Reinitialize Subscription(s) dialog box, select options, and then click Mark for Reinitialization.
To mark a single pull subscription for reinitialization in Management Studio (at the Subscriber)
3. Right-click the subscription, and then click Reinitialize.
4. In the confirmation dialog box that is displayed, click Yes.
To mark all subscriptions for reinitialization in Management Studio
3. Right-click the publication with subscriptions you want to reinitialize, and then click Reinitialize All
Subscriptions.
To mark a single push or pull subscription for reinitialization in Replication Monitor
publication.
3. Right-click the subscription you want to reinitialize, and then click Reinitialize Subscription.
To mark all subscriptions for reinitialization in Replication Monitor
2. Right-click the publication with subscriptions you want to reinitialize, and then click Reinitialize All
Subscriptions.
Using Transact-SQL
Subscriptions can be reinitialized programmatically using replication stored procedures. The stored procedure that
is used depends on the type of subscription (push or pull) and the type of publication to which the subscription
belongs.
To reinitialize a pull subscription to a transactional publication
1. At the Subscriber on the subscription database, execute sp_reinitpullsubscription (Transact-SQL). Specify
@publisher, @publisher_db, and @publication. This marks the subscription for reinitialization the next
time the Distribution Agent runs.
2. (Optional) Start the Distribution Agent at the Subscriber to synchronize the subscription. For more
information, see Synchronize a Pull Subscription.
To reinitialize a push subscription to a transactional publication
1. At the Publisher, execute sp_reinitsubscription (Transact-SQL). Specify @publication, @subscriber, and
@destination_db. This marks the subscription for reinitialization the next time the Distribution Agent runs.
2. (Optional) Start the Distribution Agent at the Distributor to synchronize the subscription. For more
information, see Synchronize a Push Subscription.
To reinitialize a pull subscription to a merge publication
1. At the Subscriber on the subscription database, execute sp_reinitmergepullsubscription (Transact-SQL).
Specify @publisher, @publisher_db, and @publication. To upload changes from the Subscriber before
reinitialization occurs, specify a value of true for @upload_first. This marks the subscription for
reinitialization the next time the Merge Agent runs.
IMPORTANT
If you add, drop, or change a parameterized filter, pending changes at the Subscriber cannot be uploaded to the
Publisher during reinitialization. If you want to upload pending changes, synchronize all subscriptions before
changing the filter.
2. (Optional) Start the Merge Agent at the Subscriber to synchronize the subscription. For more information,
see Synchronize a Pull Subscription.
To reinitialize a push subscription to a merge publication
1. At the Publisher, execute sp_reinitmergesubscription (Transact-SQL). Specify @publication, @subscriber,
and @subscriber_db. To upload changes from the Subscriber before reinitialization occurs, specify a value
of true for @upload_first. This marks the subscription for reinitialization the next time the Distribution
Agent runs.
IMPORTANT
2. (Optional) Start the Merge Agent at the Distributor to synchronize the subscription. For more information,
see Synchronize a Push Subscription.
To set the reinitialization policy when creating a new merge publication
1. At the Publisher on the publication database, execute sp_addmergepublication, specifying one of the
following values for @automatic_reinitialization_policy:
1 - changes are uploaded from the Subscriber before a subscription is automatically reinitialized as
required by a change to the publication.
0 - changes at the Subscriber are discarded when a subscription is automatically reinitialized as
IMPORTANT
For more information, see Create a Publication.

To change the reinitialization policy for an existing merge publication
1. At the Publisher on the publication database, execute sp_changemergepublication, specifying
automatic_reinitialization_policy for @property and one of the following values for @value:
1 - changes are uploaded from the Subscriber before a subscription is automatically reinitialized as
0 - changes at the Subscriber are discarded when a subscription is automatically reinitialized as
IMPORTANT
For more information, see View and Modify Publication Properties.

Individual subscriptions can be marked for reinitialization so that during the next synchronization, a new snapshot
is applied. Subscriptions can be reinitialized programmatically by using Replication Management Objects (RMO).
The classes you use depend on the type of publication to which the subscription belongs and the type of
subscription (that is, a push or pull subscription).
To reinitialize a pull subscription to a transactional publication
2. Create an instance of the TransPullSubscription class, and set PublicationName, DatabaseName,
PublisherName, PublicationDBName, and the connection from step 1 for ConnectionContext.
3. Call the LoadProperties method to get the properties of the object.
NOTE
If this method returns false, either the subscription properties in step 2 were defined incorrectly or the pull
subscription does not exist.
4. Call the Reinitialize method. This method marks the subscription for reinitialization.
5. Synchronize the pull subscription. For more information, see Synchronize a Pull Subscription.
To reinitialize a push subscription to a transactional publication
2. Create an instance of the TransSubscription class, and set PublicationName, DatabaseName,
SubscriberName, SubscriptionDBName, and the connection from step 1 for ConnectionContext.
NOTE
If this method returns false, either the subscription properties in step 2 were defined incorrectly or the push
4. Call the Reinitialize method. This method marks the subscription for reinitialization.
5. Synchronize the push subscription. For more information, see Synchronize a Push Subscription.
To reinitialize a pull subscription to a merge publication
2. Create an instance of the MergePullSubscription class, and set PublicationName, DatabaseName,
PublisherName, PublicationDBName, and the connection from step 1 for ConnectionContext.
NOTE
If this method returns false, either the subscription properties in step 2 were defined incorrectly or the pull
4. Call the Reinitialize method. Pass a value of true to upload changes at the Subscriber before reinitialization
or a value of false to reinitialize and lose any pending changes at the Subscriber. This method marks the
subscription for reinitialization.
NOTE
Changes cannot be uploaded if the subscription is expired. For more information, see Set the Expiration Period for
Subscriptions.
5. Synchronize the pull subscription. For more information, see Synchronize a Pull Subscription.
To reinitialize a push subscription to a merge publication
2. Create an instance of the MergeSubscription class, and set PublicationName, DatabaseName,
SubscriberName, SubscriptionDBName, and the connection from step 1 for ConnectionContext.
NOTE
If this method returns false, either the subscription properties in step 2 were defined incorrectly or the push
4. Call the Reinitialize method. Pass a value of true to upload changes at the Subscriber before reinitialization
or a value of false to reinitialize and lose any pending changes at the Subscriber. This method marks the
subscription for reinitialization.
NOTE
Changes cannot be uploaded if the subscription is expired. For more information, see Set the Expiration Period for
Subscriptions.
5. Synchronize the push subscription. For more information, see Synchronize a Push Subscription.
Examples (RMO )
This example reinitializes a pull subscription to a transactional publication.
String publicationName = "AdvWorksProductTran";
String publicationDbName = "AdventureWorks2012";
String subscriptionDbName = "AdventureWorks2012Replica";

try
{
conn.Connect();

// If the pull subscription and the job exists, mark the subscription
// for reinitialization and start the agent job.
{
subscription.Reinitialize();
}
else
{
}
}
{
throw new ApplicationException("The subscription could not be reinitialized.", ex);
}
finally
{
conn.Disconnect();
}

Try
conn.Connect()

' If the pull subscription and the job exists, mark the subscription
' for reinitialization and start the agent job.
If subscription.LoadProperties() And (Not subscription.AgentJobId Is Nothing) Then
subscription.Reinitialize()
Else
End If
Throw New ApplicationException("The subscription could not be reinitialized.", ex)
Finally
conn.Disconnect()
End Try
This example reinitializes a pull subscription to a merge publication after first uploading pending changes at the
Subscriber.
String publicationName = "AdvWorksSalesOrdersMerge";
String publicationDbName = "AdventureWorks2012";
String subscriptionDbName = "AdventureWorks2012Replica";

try
{
conn.Connect();

// If the pull subscription and the job exists, mark the subscription
// for reinitialization after upload and start the agent job.
{
subscription.Reinitialize(true);
}
else
{
}
}
{
}
finally
{
conn.Disconnect();
}

Try
conn.Connect()

' If the pull subscription and the job exists, mark the subscription
' for reinitialization after upload and start the agent job.
If subscription.LoadProperties() And (Not subscription.AgentJobId Is Nothing) Then
subscription.Reinitialize(True)
Else
End If
Finally
conn.Disconnect()
End Try
See Also
Execute Scripts Before and After a Snapshot Is
Applied
Warehouse
Specify an optional script to execute before or after the snapshot is applied on the Snapshot page of the
Publication Properties - <Publication> dialog box. For more information about accessing this dialog box, see
View and Modify Publication Properties.
NOTE
These options are not available if the Snapshot format option is set to Character.
To execute a script before or after a snapshot is applied

1. On the Snapshot page of the Publication Properties - <Publication> dialog box:
To specify a script to execute before the snapshot is applied, click Browse to navigate to the script, or
enter a path to the script in the Before applying the snapshot, execute this script text box.
NOTE
The Distribution Agent or Merge Agent must have read permissions for the directory you specify. If pull
subscriptions are used, you must specify a shared directory as a universal naming convention (UNC) path,
such as \\computername\scripts\myscript.sql.
To specify a script to execute after the snapshot is applied, click Browse to navigate to the script, or
enter a UNC path to the script in the After applying the snapshot, execute this script text box.
2. Click OK.
See Also
Configure Snapshot Properties (Replication Transact-SQL Programming)
Change Publication and Article Properties
Execute Scripts Before and After the Snapshot Is Applied
Execute Scripts During Synchronization (Replication
Warehouse
Replication supports on demand script execution for Subscribers to transactional and merge publications. This
functionality copies the script to the replication working directory and then uses sqlcmd to apply the script at the
Subscriber. By default, if there is a failure when applying the script for a subscription to a transactional publication,
the Distribution Agent will stop. You can specify a Transact-SQL script to execute programmatically using
replication stored procedures.
To specify a script to run for all Subscribers to a snapshot, transactional or merge publication
1. Compose and test the Transact-SQL script that will be executed on demand.
2. Save the script file to a location where it can be accessed by the Snapshot Agent for the publication.
3. At the Publisher on the publication database, execute sp_addscriptexec (Transact-SQL). Specify
@publication, the name of the script file with full UNC path created in step 2 for @scriptfile, and one of
the following values for @skiperror:
0 - the agent will stop executing the script if an error is encountered.
1 - the agent will log errors and continue executing the script when errors are encountered.
4. The specified script will be executed at each Subscriber when the agent next runs to synchronize the
subscription.
See Also
Synchronize Data
View and Resolve Data Conflicts for Merge
Publications
Warehouse
Conflicts in merge replication are resolved based on the resolver specified for each article. By default, conflicts are
resolved without the need for user intervention. But conflicts can be viewed, and the outcome of the resolution can
be changed, in the Microsoft Replication Conflict Viewer.
Conflict data is available in the Replication Conflict Viewer for the amount of time specified for the conflict
retention period (with a default of 14 days). To set the conflict retention period, either:
Specify a retention value for the @conflict_retention parameter of sp_addmergepublication (Transact-
SQL).
Specify a value of conflict_retention for the @property parameter and a retention value for the @value
parameter of sp_changemergepublication (Transact-SQL).
By default, conflict information is stored:
At the Publisher and Subscriber if the publication compatibility level is 90RTM or higher.
At the Publisher if the publication compatibility level is lower than 80RTM.
At the Publisher if Subscribers are running SQL Server Compact. Conflict data cannot be stored on SQL
Server Compact Subscribers.
Storage of conflict information is controlled by the conflict_logging publication property. For more
information, see sp_addmergepublication (Transact-SQL) and sp_changemergepublication (Transact-SQL).
Conflicts can also be resolved interactively during synchronization using the Microsoft Interactive Resolver.
The Interactive Resolver is available through the Microsoft Windows Synchronization Manager. For more
information, see Synchronize a Subscription Using Windows Synchronization Manager (Windows
Synchronization Manager).
To view and resolve conflicts for merge publications
1. Connect to the Publisher (or Subscriber if appropriate) in Microsoft SQL Server Management Studio, and
then expand the server node.
3. Right-click the publication for which you want to view conflicts, and then click View Conflicts.
NOTE
If you specified a value of 'subscriber' for the conflict_logging property, the View Conflicts menu option is not
available. To view conflicts, start ConflictViewer.exe from the command prompt. By default, ConflictViewer.exe is
located in the following directory: Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE. For a list of valid
startup parameters, run ConflictViewer.exe -?.
4. In the Select Conflict Table dialog box, select a database, publication, and table for which to view conflicts.
5. In the Replication Conflict Viewer, you can:
Filter rows with the buttons to the right of the upper grid.
Select a row in the upper grid to display information on that row in the lower grid.
Select one or more rows in the upper grid, and then click Remove, which is equivalent to clicking the
Submit Winner button (without making any changes to the data).
Click the properties button () to view more information on a column involved in a conflict.
Edit data in the Conflict winner or Conflict loser column before submitting the data (data is read-
only if the column is gray).
Click Submit Winner to accept the row designated as the winner of the conflict.
Click Submit Loser to override the resolution and to propagate the value designated as the loser of
the conflict to all nodes in the topology.
Select Log the details of this conflict to log conflict data to a file. To specify a location for the file,
point to the View menu, and then click Options. Enter a value, or click the browse button (...), and
then navigate to the appropriate file. Click OK to exit the Options dialog box.
6. Close the Replication Conflict Viewer.
See Also
Specify a Merge Article Resolver
View Conflict Information for Merge Publications
Warehouse
When a conflict is resolved in merge replication, the data from the losing row is written to a conflict table. This
conflict data can be viewed programmatically by using replication stored procedures. For more information, see
Advanced Merge Replication Conflict Detection and Resolution.
To view conflict information and losing row data for all types of conflicts
1. At the Publisher on the publication database, execute sp_helpmergepublication. Note the values of the
following columns in the result set:
centralized_conflicts - 1 indicates that conflict rows are stored at the Publisher, and 0 indicates that
conflict rows are not stored at the Publisher.
decentralized_conflicts - 1 indicates that conflict rows are stored at the Subscriber, and 0 indicates
that conflict rows are not stored at the Subscriber.
NOTE
The conflict logging behavior of a merge publication is set by using the @conflict_logging parameter of
sp_addmergepublication. Use of the @centralized_conflicts parameter has been deprecated.
The following table describes the values of these columns based on the value specified for
@conflict_logging.
@CONFLICT_LOGGING VALUE CENTRALIZED_CONFLICTS DECENTRALIZED_CONFLICTS
publisher 1 0
subscriber 0 1
both 1 1
2. At either the Publisher on the publication database or at the Subscriber on the subscription database,
execute sp_helpmergearticleconflicts. Specify a value for @publication to only return conflict information
for articles that belong to a specific publication. This returns conflict table information for articles with
conflicts. Note the value of conflict_table for any articles of interest. If the value of conflict_table for an
article is NULL, only delete conflicts have occurred in this article.
3. (Optional) Review conflict rows for articles of interest. Depending on the values of centralized_conflicts
and decentralized_conflicts from step 1, do one of the following:
At the Publisher on the publication database, execute sp_helpmergeconflictrows. Specify a conflict
table for the article (from step 1) for @conflict_table. (Optional) Specify a value of @publication to
restrict returned conflict information to a specific publication. This returns row data and other
information for the losing row.
At the Subscriber on the subscription database, execute sp_helpmergeconflictrows. Specify a conflict
table for the article (from step 1) for @conflict_table. This returns row data and other information
for the losing row.
To view information only on conflicts where the delete failed
1. At the Publisher on the publication database, execute sp_helpmergepublication. Note the values of the
following columns in the result set:
centralized_conflicts - 1 indicates that conflict rows are stored at the Publisher, and 0 indicates that
conflict rows are not stored at the Publisher.
decentralized_conflicts - 1 indicates that conflict rows are stored at the Subscriber, and 0 indicates
that conflict rows are not stored at the Subscriber.
NOTE
The conflict logging behavior of a merge publication is set using the @conflict_logging parameter of
sp_addmergepublication. Use of the @centralized_conflicts parameter has been deprecated.
2. At either the Publisher on the publication database or at the Subscriber on the subscription database,
execute sp_helpmergearticleconflicts. Specify a value for @publication to only return conflict table
information for articles that belong to a specific publication. This returns conflict table information for
articles with conflicts. Note the value of source_object for any articles of interest. If the value of
conflict_table for an article is NULL, only delete conflicts have occurred in this article.
3. (Optional) Review conflict information for delete conflicts. Depending on the values of
centralized_conflicts and decentralized_conflicts from step 1, do one of the following:
At the Publisher on the publication database, execute sp_helpmergedeleteconflictrows. Specify the
name of the source table (from step 1) on which the conflict occurred for @source_object.
(Optional) Specify a value of @publication to restrict returned conflict information to a specific
publication. This returns delete conflict information stored at the Publisher.
At the Subscriber on the subscription database, execute sp_helpmergedeleteconflictrows. Specify the
name of the source table (from step 1) on which the conflict occurred for @source_object.
(Optional) Specify a value of @publication to restrict returned conflict information to a specific
publication. This returns delete conflict information stored at the Subscriber.
See Also
View Data Conflicts for Transactional Publications
(SQL Server Management Studio)
Warehouse
You can view conflicts for peer-to-peer transactional replication and transactional replication with queued
updating subscriptions in the Microsoft Replication Conflict Viewer. For information about how conflicts are
detected and resolved, see Conflict Detection in Peer-to-Peer Replication and Set Queued Updating Conflict
Resolution Options (SQL Server Management Studio).
The availability of conflict data depends on the type of replication and the conflict retention period:
For peer-to-peer replication, by default, the Distribution Agent fails when it detects a conflict. A conflict error
is logged into the error log, but no conflict data is logged into the conflict table; therefore it is not available
for viewing. If the Distribution Agent is allowed to continue, a conflict is logged locally on each node where
it was detected. For more information, see "Handling Conflicts" in Conflict Detection in Peer-to-Peer
Replication.
For queued updating subscriptions, data is available for every conflict. Conflict data is available in the
Replication Conflict Viewer for the amount of time specified for the conflict retention period, with a default
of 14 days. To set the conflict retention period, perform either of the following:
Specify a retention value for the @conflict_retention parameter of sp_addpublication.
Specify a value of 'conflict_retention' for the @property parameter and a retention value for the
@value parameter of sp_changepublication.
To view conflicts
1. Connect to the appropriate server in SQL Server Management Studio, and then expand the server node:
For peer-to-peer replication, this is the node at which the conflict occurred.
For queued updating subscriptions, this is the Publisher.
3. Right-click the publication for which you want to view conflicts, and then click View Conflicts.
4. In the Select Conflict Table dialog box, select a database, publication, and table for which to view conflicts.
5. In the Replication Conflict Viewer, you can:
Filter rows with the buttons to the right of the upper grid.
Select a row in the upper grid to display information on that row in the lower grid.
Select one or more rows in the upper grid, and then click Remove, which removes the row from the
conflicts metadata table.
Click the properties button () to view more information on a column involved in a conflict.
Select Log the details of this conflict to log conflict data to a file. To specify a location for the file,
point to the View menu, and then click Options. Enter a value, or click the browse button (...), and
then navigate to the appropriate file. Click OK to close the Options dialog box.
6. Close the Replication Conflict Viewer.
See Also
Peer-to-Peer Transactional Replication
Queued Updating Conflict Detection and Resolution
Synchronize a Subscription Using Windows
Synchronization Manager
Warehouse
Microsoft Windows Synchronization Manager can only be used to synchronize subscriptions to Microsoft SQL
Server publications if SQL Server is running on the same computer as Synchronization Manager (it can also be
used to synchronize offline files and Web pages). To use Synchronization Manager:
1. Enable the synchronization of pull subscriptions with Windows Synchronization Manager in the
Subscription Properties - <Subscriber>: <SubscriptionDatabase> dialog box. For more information
about accessing this dialog box, see View and Modify Pull Subscription Properties.
2. Access Synchronization Manager through the Start menu in Windows.
Synchronization Manager allows you to use the Interactive Resolver for merge subscriptions. Typically,
conflicts detected during synchronization are resolved automatically, but if interactive resolution is enabled,
conflicts can be resolved by a user during synchronization. If a synchronization is performed outside of
Windows Synchronization Manager (as a scheduled synchronization or an on demand synchronization in
SQL Server Management Studio or Replication Monitor), conflicts are resolved automatically without user
intervention, according to the resolver specified for the article.
NOTE
Beginning with Windows Server 2008 and Windows Vista, 64-bit versions of the Windows Synchronization Manager cannot
detect 32-bit subscriptions.
To enable the synchronization of pull subscriptions with Windows Synchronization Manager

1. On the General page of the Subscription Properties - <Subscriber>: <SubscriptionDatabase> dialog
box, select a value of Enable for the Use Windows Synchronization Manager option.
2. Click OK.
To synchronize a pull subscription with Synchronization Manager
1. Launch Synchronization Manager using one of the following methods:
In Internet Explorer, click Tools, and then click Synchronize.
Click Start, point to Programs or All Programs, point to Accessories, and then click Synchronize.
Click Start, and then click Run. In the Run dialog box, type mobsync.exe in the Open field, and then
click OK.
2. In the Items to Synchronize dialog box, select the subscriptions to synchronize. Subscriptions are listed
under the SQL Server instances installed on the computer.
3. Click Synchronize.
To reinitialize a pull subscription with Synchronization Manager
1. In the Items to Synchronize dialog box, select a subscription, and then click Properties.
2. In the SQL Server Subscription Properties dialog box, click Reinitialize Subscription.
3. Click Yes.
4. Click OK.
The next time the subscription is synchronized, by default a new snapshot is applied to the subscription
database. For more information, see Reinitialize Subscriptions.
NOTE
Merge replication allows any outstanding changes to be uploaded to the Publisher before the snapshot is applied, but this
option is not available from Synchronization Manager. To upload changes, synchronize the subscription before reinitializing
it.
To set properties for a pull subscription in Synchronization Manager

2. View and modify properties on the following tabs:
Identification
Subscriber Login, Distributor Login, and Publisher Login (for merge replication only)
Web Server Information (for merge subscriptions on Subscribers running SQL Server 2005 or
later)
Other
It is recommended to use Windows Authentication for all connections. For information about the
permissions required by the Distribution Agent and the Merge Agent, see Replication Agent Security
Model.
3. Click OK.
To remove a pull subscription from Synchronization Manager
2. In the SQL Server Subscription Properties dialog box, click Remove Subscription.
3. Select an option in the Remove Subscription dialog box.
4. Click OK.
To use the Interactive Resolver
1. Enable the article and subscription to use interactive resolution. For more information, see Specify
Interactive Conflict Resolution for Merge Articles.
2. After the subscription begins synchronizing in Synchronization Manager, the Interactive Resolver launches
automatically if interactive conflict resolution is enabled and there are conflicts for one or more articles. The
Interactive Resolver displays conflicts one at a time, with a suggested resolution for each conflict (based on
the resolver specified when the publication and subscription were created).
3. Optionally edit any of the columns displayed in the Interactive Resolver, and then click one of the following
buttons to resolve the conflict:
Accept Suggested
Accept Publisher
Accept Subscriber
Resolve All Automatically (all current conflicts are resolved without further input)
The selected row is then applied to the Publisher and/or Subscriber; it is propagated to other nodes
in the topology during subsequent synchronizations.
NOTE
Edits are only applied if they are part of the row that is chosen for resolution. For example, if you make edits under
Publisher, and then click Accept Subscriber, the edits are discarded.
See Also
Interactive Conflict Resolution
Control Behavior of Triggers and Constraints in
Synchronization
Warehouse
During synchronization, replication agents execute INSERT (Transact-SQL), UPDATE (Transact-SQL), and DELETE
(Transact-SQL) statements on replicated tables, which can cause data manipulation language (DML) triggers on
these tables to be executed. There are cases when you may need to prevent these triggers from firing or constraints
from being enforced during synchronization. This behavior depends on how the trigger or constraint is created.
To prevent triggers from executing during synchronization
1. When creating a new trigger, specify the NOT FOR REPLICATION option of CREATE TRIGGER (Transact-SQL).
2. For an existing trigger, specify the NOT FOR REPLICATION option of ALTER TRIGGER (Transact-SQL).
To prevent constraints from being enforced during synchronization
1. When creating a new CHECK or FOREIGN KEY constraint, specify CHECK NOT FOR REPLICATION option in the
constraint definition of CREATE TABLE (Transact-SQL).
See Also
Create Tables (Database Engine)
Implement a Business Logic Handler for a Merge
Article
Warehouse
This topic describes how to implement a business logic handler for a merge article in SQL Server 2017 by using
replication programming or Replication Management Objects (RMO).
The Microsoft.SqlServer.Replication.BusinessLogicSupport namespace implements an interface that enables you to
write complex business logic to handle events that occur during the merge replication synchronization process.
Methods in the business logic handler can be invoked by the replication process for each changed row that is
replicated during synchronization.
The general process for implementing a business logic handler is:
1. Create the business logic hander assembly.
2. Register the assembly at the Distributor.
3. Deploy the assembly at the server on which the Merge Agent runs. For a pull subscription the agent runs on
the Subscriber, and for a push subscription the agent runs on the Distributor. When you are using Web
synchronization, the agent runs on the Web server.
4. Create an article that uses the business logic handler or modify an existing article to use the business logic
handler.
The business logic handler you specify is executed for every row that is synchronized. Complex logic and
calls to other applications or network services can impact performance. For more information about
business logic handlers, see Execute Business Logic During Merge Synchronization.
In This Topic
To implement a business logic handler for a merge article, using:
Replication Programming
Using Replication Programming

To create and deploy a business logic handler
1. In Microsoft Visual Studio, create a new project for the .NET assembly that contains the code that
implements the business logic handler.
2. Add references to the project for the following namespaces.
ASSEMBLY REFERENCE LOCATION
Microsoft.SqlServer.Replication.BusinessLogicSupport C:\Program Files\Microsoft SQL Server\nnn\COM (default

installation)
System.Data GAC (component of the .NET Framework)

System.Data.Common GAC (component of the .NET Framework)
3. Add a class that overrides the BusinessLogicModule class.

4. Implement the HandledChangeStates property to indicate the types of changes that are handled.
5. Override one or more of the following methods of the BusinessLogicModule class:
CommitHandler - invoked when a data change is committed during synchronization.
DeleteErrorHandler - invoked when an error occurs when a DELETE statement is being uploaded or
downloaded.
DeleteHandler - invoked when DELETE statements are being uploaded or downloaded.
InsertErrorHandler - invoked when an error occurs when an INSERT statement is being uploaded or
downloaded.
InsertHandler - invoked when INSERT statements are being uploaded or downloaded.
UpdateConflictsHandler - invoked when conflicting UPDATE statements occur at the Publisher and
Subscriber.
UpdateDeleteConflictHandler - invoked when UPDATE statements conflict with DELETE statements at
the Publisher and Subscriber.
UpdateErrorHandler - invoked when an error occurs when an UPDATE statement is being uploaded
or downloaded.
UpdateHandler - invoked when UPDATE statements are being uploaded or downloaded.
6. Build the project to create the business logic handler assembly.
7. Deploy the assembly in the directory that contains the Merge Agent executable file (replmerg.exe), which for
a default installation is C:\Program Files\Microsoft SQL Server\nnn\COM, or install it in the .NET global
assembly cache (GAC). You should only install the assembly in the GAC if applications other than the Merge
Agent require access to the assembly. The assembly can be installed into the GAC using the Global
Assembly Cache tool (Gacutil.exe) provided in the .NET Framework SDK.
NOTE
A business logic handler must be deployed on every server on which the Merge Agent runs, which includes the IIS
server that hosts the replisapi.dll when using Web synchronization.
To register a business logic handler

1. At the Publisher, execute sp_enumcustomresolvers (Transact-SQL) to verify that the assembly has not
already been registered as a business logic handler.
2. At the Distributor, execute sp_registercustomresolver (Transact-SQL), specifying a friendly name for the
business logic handler for @article_resolver, a value of true for @is_dotnet_assembly, the name of the
assembly for @dotnet_assembly_name, and the fully-qualified name of the class that overrides
BusinessLogicModule for @dotnet_class_name.
NOTE
If the assembly is not deployed in the same directory as the Merge Agent executable, in the same directory as the
application that synchronously starts the Merge Agent, or in the global assembly cache (GAC), you need to specify
the full path with the assembly name for @dotnet_assembly_name. When using Web synchronization, you must
specify the location of assembly at the Web server.
To use a business logic handler with a new table article

1. Execute sp_addmergearticle (Transact-SQL) to define an article, specifying the friendly name of the business
logic handler for @article_resolver. For more information, see Define an Article.
To use a business logic handler with an existing table article
1. Execute sp_changemergearticle (Transact-SQL), specifying @publication, @article, a value of
article_resolver for @property, and the friendly name of the business logic handler for @value.
Examples (Replication Programming)
This example shows a business logic handler that creates an audit log.
using System;
using System.Text;
using System.Data;
using System.Data.Common;
using Microsoft.SqlServer.Replication.BusinessLogicSupport;
using Microsoft.Samples.SqlServer.BusinessLogicHandler;
namespace Microsoft.Samples.SqlServer.BusinessLogicHandler
{
public class OrderEntryBusinessLogicHandler :
Microsoft.SqlServer.Replication.BusinessLogicSupport.BusinessLogicModule
{
// Variables to hold server names.
private string publisherName;
private string subscriberName;
public OrderEntryBusinessLogicHandler()
{
}
// Implement the Initialize method to get publication

// and subscription information.
public override void Initialize(
string publisher,
string subscriber,
string distributor,
string publisherDB,
string subscriberDB,
string articleName)
{
// Set the Publisher and Subscriber names.
publisherName = publisher;
subscriberName = subscriber;
}
// Declare what types of row changes, conflicts, or errors to handle.

override public ChangeStates HandledChangeStates
{
get
{
// Handle Subscriber inserts, updates and deletes.
return ChangeStates.SubscriberInserts |
ChangeStates.SubscriberUpdates | ChangeStates.SubscriberDeletes;
}
}
public override ActionOnDataChange InsertHandler(SourceIdentifier insertSource,
DataSet insertedDataSet, ref DataSet customDataSet, ref int historyLogLevel,
ref string historyLogMessage)
{
if (insertSource == SourceIdentifier.SourceIsSubscriber)
{
// Build a line item in the audit message to log the Subscriber insert.
StringBuilder AuditMessage = new StringBuilder();
AuditMessage.Append(String.Format("A new order was entered at {0}. " +
"The SalesOrderID for the order is :", subscriberName));
AuditMessage.Append(insertedDataSet.Tables[0].Rows[0]["SalesOrderID"].ToString());
AuditMessage.Append("The order must be shipped by :");
AuditMessage.Append(insertedDataSet.Tables[0].Rows[0]["DueDate"].ToString());
// Set the reference parameter to write the line to the log file.
historyLogMessage = AuditMessage.ToString();
// Set the history log level to the default verbose level.

historyLogLevel = 1;
// Accept the inserted data in the Subscriber's data set and

// apply it to the Publisher.
return ActionOnDataChange.AcceptData;
}
else
{
return base.InsertHandler(insertSource, insertedDataSet, ref customDataSet,
ref historyLogLevel, ref historyLogMessage);
}
}
public override ActionOnDataChange UpdateHandler(SourceIdentifier updateSource,

DataSet updatedDataSet, ref DataSet customDataSet, ref int historyLogLevel,
{
if (updateSource == SourceIdentifier.SourceIsPublisher)
{
// Build a line item in the audit message to log the Subscriber update.
AuditMessage.Append(String.Format("An existing order was updated at {0}. " +
"The SalesOrderID for the order is ", subscriberName));
AuditMessage.Append(updatedDataSet.Tables[0].Rows[0]["SalesOrderID"].ToString());
AuditMessage.Append("The order must now be shipped by :");
AuditMessage.Append(updatedDataSet.Tables[0].Rows[0]["DueDate"].ToString());
// Accept the updated data in the Subscriber's data set and apply it to the Publisher.
}
else
{
return base.UpdateHandler(updateSource, updatedDataSet,
ref customDataSet, ref historyLogLevel, ref historyLogMessage);
}
}
public override ActionOnDataDelete DeleteHandler(SourceIdentifier deleteSource,

DataSet deletedDataSet, ref int historyLogLevel, ref string historyLogMessage)
{
if (deleteSource == SourceIdentifier.SourceIsSubscriber)
{
// Build a line item in the audit message to log the Subscriber deletes.
// Note that the rowguid is the only information that is
// available in the dataset.
AuditMessage.Append(String.Format("An existing order was deleted at {0}. " +
"The rowguid for the order is ", subscriberName));
AuditMessage.Append(deletedDataSet.Tables[0].Rows[0]["rowguid"].ToString());
// Accept the delete and apply it to the Publisher.

return ActionOnDataDelete.AcceptDelete;
}
else
{
return base.DeleteHandler(deleteSource, deletedDataSet,
}
}
}
}
Imports System
Imports System.Text
Imports System.Data
Imports System.Data.Common
Imports Microsoft.SqlServer.Replication.BusinessLogicSupport
Namespace Microsoft.Samples.SqlServer.BusinessLogicHandler
Public Class OrderEntryBusinessLogicHandler
Inherits BusinessLogicModule
' Variables to hold server names.

Private publisherName As String
Private subscriberName As String
' Implement the Initialize method to get publication

' and subscription information.
Public Overrides Sub Initialize( _
ByVal publisher As String, _
ByVal subscriber As String, _
ByVal distributor As String, _
ByVal publisherDB As String, _
ByVal subscriberDB As String, _
ByVal articleName As String _
)
' Set the Publisher and Subscriber names.
publisherName = publisher
subscriberName = subscriber
End Sub
' Declare what types of row changes, conflicts, or errors to handle.

Public Overrides ReadOnly Property HandledChangeStates() As ChangeStates
Get
' Handle Subscriber inserts, updates and deletes.
Return (ChangeStates.SubscriberInserts Or _
ChangeStates.SubscriberUpdates Or ChangeStates.SubscriberDeletes)
End Get
End Property
Public Overrides Function InsertHandler(ByVal insertSource As SourceIdentifier, _

ByVal insertedDataSet As DataSet, ByRef customDataSet As DataSet, _
ByRef historyLogLevel As Integer, ByRef historyLogMessage As String) _
As ActionOnDataChange
If insertSource = SourceIdentifier.SourceIsSubscriber Then

' Build a line item in the audit message to log the Subscriber insert.
Dim AuditMessage As StringBuilder = New StringBuilder()
AuditMessage.Append(String.Format("A new order was entered at {0}. " + _
"The SalesOrderID for the order is :", subscriberName))
AuditMessage.Append(insertedDataSet.Tables(0).Rows(0)("SalesOrderID").ToString())
AuditMessage.Append("The order must be shipped by :")
AuditMessage.Append(insertedDataSet.Tables(0).Rows(0)("DueDate").ToString())
' Set the reference parameter to write the line to the log file.
historyLogMessage = AuditMessage.ToString()
' Set the history log level to the default verbose level.
historyLogLevel = 1
' Accept the inserted data in the Subscriber's data set and
' apply it to the Publisher.
Return ActionOnDataChange.AcceptData
Else
Return MyBase.InsertHandler(insertSource, insertedDataSet, customDataSet, _
historyLogLevel, historyLogMessage)
End If
End Function
Public Overrides Function UpdateHandler(ByVal updateSource As SourceIdentifier, _
ByVal updatedDataSet As DataSet, ByRef customDataSet As DataSet, _
If updateSource = SourceIdentifier.SourceIsPublisher Then

' Build a line item in the audit message to log the Subscriber update.
AuditMessage.Append(String.Format("An existing order was updated at {0}. " + _
"The SalesOrderID for the order is ", subscriberName))
AuditMessage.Append(updatedDataSet.Tables(0).Rows(0)("SalesOrderID").ToString())
AuditMessage.Append("The order must now be shipped by :")
AuditMessage.Append(updatedDataSet.Tables(0).Rows(0)("DueDate").ToString())
historyLogLevel = 1
' Accept the updated data in the Subscriber's data set and apply it to the Publisher.
Else
Return MyBase.UpdateHandler(updateSource, updatedDataSet, _
customDataSet, historyLogLevel, historyLogMessage)
End If
End Function
Public Overrides Function DeleteHandler(ByVal deleteSource As SourceIdentifier, _
ByVal deletedDataSet As DataSet, ByRef historyLogLevel As Integer, _
ByRef historyLogMessage As String) As ActionOnDataDelete
If deleteSource = SourceIdentifier.SourceIsSubscriber Then
' Build a line item in the audit message to log the Subscriber deletes.
' Note that the rowguid is the only information that is
' available in the dataset.
AuditMessage.Append(String.Format("An existing order was deleted at {0}. " + _
"The rowguid for the order is ", subscriberName))
AuditMessage.Append(deletedDataSet.Tables(0).Rows(0)("rowguid").ToString())
historyLogLevel = 1
' Accept the delete and apply it to the Publisher.

Return ActionOnDataDelete.AcceptDelete
Else
Return MyBase.DeleteHandler(deleteSource, deletedDataSet, _
End If
End Function
End Class
End Namespace
The following example registers a business logic handler assembly at the Distributor and changes an existing
merge article to use this custom business logic.

DECLARE @article AS sysname;
DECLARE @friendlyname AS sysname;
DECLARE @assembly AS nvarchar(500);
DECLARE @class AS sysname;
SET @publication = N'AdvWorksCustomers';
SET @article = N'Customers';
SET @friendlyname = N'OrderEntryLogic';
SET @assembly = N'C:\Program Files\Microsoft SQL Server\120\COM\CustomLogic.dll';
SET @class = N'Microsoft.Samples.SqlServer.BusinessLogicHandler.OrderEntryBusinessLogicHandler';
-- Register the business logic handler at the Distributor.

EXEC sys.sp_registercustomresolver
@article_resolver = @friendlyname,
@resolver_clsid = NULL,
@is_dotnet_assembly = N'true',
@dotnet_assembly_name = @assembly,
@dotnet_class_name = @class;
-- Add an article that uses the business logic handler

-- at the Publisher.
EXEC sp_changemergearticle
@article = @article,
@property = N'article_resolver',
@value = @friendlyname,
@force_invalidate_snapshot = 0,
@force_reinit_subscription = 0;
GO

To create a business logic handler
1. In Microsoft Visual Studio, create a new project for the .NET assembly that contains the code that
2. Add references to the project for the following namespaces.
Microsoft.SqlServer.Replication.BusinessLogicSupport C:\Program Files\Microsoft SQL Server\nnn\COM (default

installation)
System.Data GAC (component of the .NET Framework)
System.Data.Common GAC (component of the .NET Framework)
3. Add a class that overrides the BusinessLogicModule class.

4. Implement the HandledChangeStates property to indicate the types of changes that are handled.
5. Override one or more of the following methods of the BusinessLogicModule class:
CommitHandler - invoked when a data change is committed during synchronization.
DeleteErrorHandler - invoked if an error occurs while a DELETE statement is being uploaded or
downloaded.
DeleteHandler - invoked when DELETE statements are being uploaded or downloaded.
InsertErrorHandler - invoked if an error occurs when an INSERT statement is being uploaded or
downloaded.
InsertHandler - invoked when INSERT statements are being uploaded or downloaded.
UpdateConflictsHandler - invoked when conflicting UPDATE statements occur at the Publisher and
Subscriber.
UpdateDeleteConflictHandler - invoked when UPDATE statements conflict with DELETE statements at
the Publisher and Subscriber.
UpdateErrorHandler - invoked if an error occurs when an UPDATE statement is being uploaded or
downloaded.
UpdateHandler - invoked when UPDATE statements are being uploaded or downloaded.
NOTE
Any article conflicts not explicitly handled by your custom business logic are handled by the default resolver for the
article.
6. Build the project to create the business logic handler assembly.

To register a business logic handler
3. Call EnumBusinessLogicHandlers and check the returned ArrayList object to ensure that the assembly has
not already been registered as a business logic handler.
4. Create an instance of the BusinessLogicHandler class. Specify the following properties:
DotNetAssemblyName - the name of the .NET assembly. If the assembly is not deployed in the same
directory as the Merge Agent executable, in the same directory as the application that synchronously
starts the Merge Agent, or in the GAC, you must include the full path with the assembly name. You
must include the full path with the assembly name when using a business logic handler with Web
synchronization.
DotNetClassName - the fully-qualified name of the class that overrides BusinessLogicModule and
FriendlyName - a friendly name you use when you access the business logic handler.
IsDotNetAssembly - a value of true.
To deploy a business logic handler
1. Deploy the assembly on the server where the Merge Agent runs in the file location specified when the business
logic handler was registered at the Distributor. For a pull subscription the agent runs on the Subscriber, and for
a push subscription the agent runs on the Distributor. When you are using Web synchronization, the agent runs
on the Web server. If the full path was not included with the assembly name when the business logic handler
was registered, deploy the assembly in the same directory as the Merge Agent executable, in the same directory
as the application that synchronously starts the Merge Agent. You may install the assembly in the GAC if there
are multiple applications that use the same assembly.
To use a business logic handler with a new table article
2. Create an instance of the MergeArticle class. Set the following properties:
The name of the article for Name.
The name of the publication for PublicationName.
The name of the publication database for DatabaseName.
The friendly name of the business logic handler (FriendlyName) for ArticleResolver.
3. Call the Create method. For more information, see Define an Article.
To use a business logic handler with an existing table article
2. Create an instance of the MergeArticle class.
3. Set the Name, PublicationName, and DatabaseName properties.
article properties in step 3 were defined incorrectly or the article does not exist. For more information, see
View and Modify Article Properties.
6. Set the friendly name of the business logic handler for ArticleResolver. This is the value of the
FriendlyName property specified when registering the business logic handler.
Examples (RMO )
This example is a business logic handler that logs information about inserts, updates, and deletes at the Subscriber.
using System;
using System.Text;
using System.Data;
using System.Data.Common;
using Microsoft.SqlServer.Replication.BusinessLogicSupport;
using Microsoft.Samples.SqlServer.BusinessLogicHandler;
namespace Microsoft.Samples.SqlServer.BusinessLogicHandler
{
public class OrderEntryBusinessLogicHandler :
Microsoft.SqlServer.Replication.BusinessLogicSupport.BusinessLogicModule
{
// Variables to hold server names.
private string publisherName;
private string subscriberName;
public OrderEntryBusinessLogicHandler()
{
}
// Implement the Initialize method to get publication

// and subscription information.
public override void Initialize(
string publisher,
string subscriber,
string distributor,
string publisherDB,
string articleName)
{
// Set the Publisher and Subscriber names.
publisherName = publisher;
subscriberName = subscriber;
}
// Declare what types of row changes, conflicts, or errors to handle.

override public ChangeStates HandledChangeStates
{
get
{
// Handle Subscriber inserts, updates and deletes.
return ChangeStates.SubscriberInserts |
ChangeStates.SubscriberUpdates | ChangeStates.SubscriberDeletes;
}
}
public override ActionOnDataChange InsertHandler(SourceIdentifier insertSource,

DataSet insertedDataSet, ref DataSet customDataSet, ref int historyLogLevel,
{
if (insertSource == SourceIdentifier.SourceIsSubscriber)
{
// Build a line item in the audit message to log the Subscriber insert.
AuditMessage.Append(String.Format("A new order was entered at {0}. " +
"The SalesOrderID for the order is :", subscriberName));
AuditMessage.Append(insertedDataSet.Tables[0].Rows[0]["SalesOrderID"].ToString());
AuditMessage.Append("The order must be shipped by :");
AuditMessage.Append(insertedDataSet.Tables[0].Rows[0]["DueDate"].ToString());

// Accept the inserted data in the Subscriber's data set and

// apply it to the Publisher.
}
else
{
return base.InsertHandler(insertSource, insertedDataSet, ref customDataSet,
}
}
public override ActionOnDataChange UpdateHandler(SourceIdentifier updateSource,

DataSet updatedDataSet, ref DataSet customDataSet, ref int historyLogLevel,
{
if (updateSource == SourceIdentifier.SourceIsPublisher)
{
// Build a line item in the audit message to log the Subscriber update.
AuditMessage.Append(String.Format("An existing order was updated at {0}. " +
"The SalesOrderID for the order is ", subscriberName));
AuditMessage.Append(updatedDataSet.Tables[0].Rows[0]["SalesOrderID"].ToString());
AuditMessage.Append("The order must now be shipped by :");
AuditMessage.Append(updatedDataSet.Tables[0].Rows[0]["DueDate"].ToString());
}
else
{
return base.UpdateHandler(updateSource, updatedDataSet,
ref customDataSet, ref historyLogLevel, ref historyLogMessage);
}
}
public override ActionOnDataDelete DeleteHandler(SourceIdentifier deleteSource,

DataSet deletedDataSet, ref int historyLogLevel, ref string historyLogMessage)
{
if (deleteSource == SourceIdentifier.SourceIsSubscriber)
{
// Build a line item in the audit message to log the Subscriber deletes.
// Note that the rowguid is the only information that is
// available in the dataset.
AuditMessage.Append(String.Format("An existing order was deleted at {0}. " +
"The rowguid for the order is ", subscriberName));
AuditMessage.Append(deletedDataSet.Tables[0].Rows[0]["rowguid"].ToString());
// Accept the delete and apply it to the Publisher.

return ActionOnDataDelete.AcceptDelete;
}
else
{
return base.DeleteHandler(deleteSource, deletedDataSet,
}
}
}
}
Imports System
Imports System.Text
Imports System.Data
Imports System.Data.Common
Imports Microsoft.SqlServer.Replication.BusinessLogicSupport
Namespace Microsoft.Samples.SqlServer.BusinessLogicHandler
Public Class OrderEntryBusinessLogicHandler
Inherits BusinessLogicModule
' Variables to hold server names.

Private publisherName As String
Private subscriberName As String
' Implement the Initialize method to get publication

' and subscription information.
Public Overrides Sub Initialize( _
ByVal publisher As String, _
ByVal subscriber As String, _
ByVal distributor As String, _
ByVal publisherDB As String, _
ByVal subscriberDB As String, _
ByVal articleName As String _
)
' Set the Publisher and Subscriber names.
publisherName = publisher
subscriberName = subscriber
End Sub
End Sub
' Declare what types of row changes, conflicts, or errors to handle.

Public Overrides ReadOnly Property HandledChangeStates() As ChangeStates
Get
' Handle Subscriber inserts, updates and deletes.
Return (ChangeStates.SubscriberInserts Or _
ChangeStates.SubscriberUpdates Or ChangeStates.SubscriberDeletes)
End Get
End Property
Public Overrides Function InsertHandler(ByVal insertSource As SourceIdentifier, _

ByVal insertedDataSet As DataSet, ByRef customDataSet As DataSet, _
If insertSource = SourceIdentifier.SourceIsSubscriber Then

' Build a line item in the audit message to log the Subscriber insert.
AuditMessage.Append(String.Format("A new order was entered at {0}. " + _
"The SalesOrderID for the order is :", subscriberName))
AuditMessage.Append(insertedDataSet.Tables(0).Rows(0)("SalesOrderID").ToString())
AuditMessage.Append("The order must be shipped by :")
AuditMessage.Append(insertedDataSet.Tables(0).Rows(0)("DueDate").ToString())
historyLogLevel = 1
' Accept the inserted data in the Subscriber's data set and
' apply it to the Publisher.
Else
Return MyBase.InsertHandler(insertSource, insertedDataSet, customDataSet, _
End If
End Function
Public Overrides Function UpdateHandler(ByVal updateSource As SourceIdentifier, _
ByVal updatedDataSet As DataSet, ByRef customDataSet As DataSet, _
If updateSource = SourceIdentifier.SourceIsPublisher Then

' Build a line item in the audit message to log the Subscriber update.
AuditMessage.Append(String.Format("An existing order was updated at {0}. " + _
"The SalesOrderID for the order is ", subscriberName))
AuditMessage.Append(updatedDataSet.Tables(0).Rows(0)("SalesOrderID").ToString())
AuditMessage.Append("The order must now be shipped by :")
AuditMessage.Append(updatedDataSet.Tables(0).Rows(0)("DueDate").ToString())
historyLogLevel = 1
' Accept the updated data in the Subscriber's data set and apply it to the Publisher.
Else
Return MyBase.UpdateHandler(updateSource, updatedDataSet, _
customDataSet, historyLogLevel, historyLogMessage)
End If
End Function
Public Overrides Function DeleteHandler(ByVal deleteSource As SourceIdentifier, _
ByVal deletedDataSet As DataSet, ByRef historyLogLevel As Integer, _
ByRef historyLogMessage As String) As ActionOnDataDelete
If deleteSource = SourceIdentifier.SourceIsSubscriber Then
' Note that the rowguid is the only information that is
' available in the dataset.
AuditMessage.Append(String.Format("An existing order was deleted at {0}. " + _
"The rowguid for the order is ", subscriberName))
AuditMessage.Append(deletedDataSet.Tables(0).Rows(0)("rowguid").ToString())
historyLogLevel = 1
' Accept the delete and apply it to the Publisher.

Return ActionOnDataDelete.AcceptDelete
Else
Return MyBase.DeleteHandler(deleteSource, deletedDataSet, _
End If
End Function
End Class
End Namespace
This example registers a business logic handler at the Distributor.

// Specify the Distributor name and business logic properties.
string assemblyName = @"C:\Program Files\Microsoft SQL Server\110\COM\CustomLogic.dll";
string className = "Microsoft.Samples.SqlServer.BusinessLogicHandler.OrderEntryBusinessLogicHandler";
string friendlyName = "OrderEntryLogic";
BusinessLogicHandler customLogic;
// Create a connection to the Distributor.

try
{
// Connect to the Distributor.
distributorConn.Connect();
// Set the Distributor properties.

distributor = new ReplicationServer(distributorConn);
// Set the business logic handler properties.

customLogic = new BusinessLogicHandler();
customLogic.DotNetAssemblyName = assemblyName;
customLogic.DotNetClassName = className;
customLogic.FriendlyName = friendlyName;
customLogic.IsDotNetAssembly = true;
Boolean isRegistered = false;
// Check if the business logic handler is already registered at the Distributor.

foreach (BusinessLogicHandler registeredLogic
in distributor.EnumBusinessLogicHandlers())
{
if (registeredLogic == customLogic)
{
isRegistered = true;
}
}
// Register the custom logic.

if (!isRegistered)
{
distributor.RegisterBusinessLogicHandler(customLogic);
}
}
{
throw new ApplicationException(string.Format(
"The {0} assembly could not be registered.",
assemblyName), ex);
}
finally
{
distributorConn.Disconnect();
}
' Specify the Distributor name and business logic properties.
Dim assemblyName As String = "C:\Program Files\Microsoft SQL Server\110\COM\CustomLogic.dll"
Dim className As String = "Microsoft.Samples.SqlServer.BusinessLogicHandler.OrderEntryBusinessLogicHandler"
Dim friendlyName As String = "OrderEntryLogic"

Dim customLogic As BusinessLogicHandler
' Create a connection to the Distributor.

Try
' Connect to the Distributor.
distributorConn.Connect()
' Set the Distributor properties.

distributor = New ReplicationServer(distributorConn)
' Set the business logic handler properties.

customLogic = New BusinessLogicHandler()
customLogic.DotNetAssemblyName = assemblyName
customLogic.DotNetClassName = className
customLogic.FriendlyName = friendlyName
customLogic.IsDotNetAssembly = True
Dim isRegistered As Boolean = False
' Check if the business logic handler is already registered at the Distributor.
For Each registeredLogic As BusinessLogicHandler _
In distributor.EnumBusinessLogicHandlers
If registeredLogic Is customLogic Then
isRegistered = True
End If
Next
' Register the custom logic.

If Not isRegistered Then
distributor.RegisterBusinessLogicHandler(customLogic)
End If
"The {0} assembly could not be registered.", _
assemblyName), ex)
Finally
End Try
This example changes an existing article to use the business logic handler.
// Define the Publisher, publication, and article names.
string articleName = "SalesOrderHeader";
// Set the friendly name of the business logic handler.

string customLogic = "OrderEntryLogic";
MergeArticle article = new MergeArticle();

try
{
conn.Connect();
// Set the required properties for the article.

article.ConnectionContext = conn;
article.Name = articleName;
article.DatabaseName = publicationDbName;
article.PublicationName = publicationName;
// Load the article properties.

if (article.LoadProperties())
{
article.ArticleResolver = customLogic;
}
else
{
// Throw an exception of the article does not exist.
"{0} is not published in {1}", articleName, publicationName));
}
}
{
// Do error handling here and rollback the transaction.
"The business logic handler {0} could not be associated with " +
" the {1} article.",customLogic,articleName), ex);
}
finally
{
conn.Disconnect();
}
' Define the Publisher, publication, and article names.
Dim articleName As String = "SalesOrderHeader"
' Set the friendly name of the business logic handler.

Dim customLogic As String = "OrderEntryLogic"
Dim article As MergeArticle = New MergeArticle()

Try
conn.Connect()
' Set the required properties for the article.

article.ConnectionContext = conn
article.Name = articleName
article.DatabaseName = publicationDbName
article.PublicationName = publicationName
' Load the article properties.

If article.LoadProperties() Then
article.ArticleResolver = customLogic
Else
' Throw an exception of the article does not exist.
"{0} is not published in {1}", articleName, publicationName))
End If
' Do error handling here and rollback the transaction.
"The business logic handler {0} could not be associated with " + _
" the {1} article.", customLogic, articleName), ex)
Finally
conn.Disconnect()
End Try
See Also
Debug a Business Logic Handler (Replication Programming)
Debug a Business Logic Handler (Replication
Programming)
Warehouse
Use a business logic handler to invoke custom business logic when a merge subscription is synchronized. For more
information, see Execute Business Logic During Merge Synchronization.
The Merge Replication Reconciler (replrec.dll) calls the managed code assembly containing the business logic. In
most cases, replrec.dll and the custom business logic is executed on the computer where the Merge Agent runs (at
the Subscriber for a pull subscription or at the Distributor for a push subscription). In the case of Web
synchronization, or in the case of a SQL Server Compact Subscriber, the reconciler and the custom business logic is
executed on the Web server.
To debug a business logic handler on a local computer
1. Configure publishing and distribution, create a publication, and create a subscription to the publication. For
more information, see Configure Publishing and Distribution and Create, Modify, and Delete Publications
and Articles (Replication).
2. Create and register a business logic handler. For more information, see Implement a Business Logic Handler
for a Merge Article.
3. Create a Replication Management Objects (RMO) project in Microsoft Visual Studio that programmatically
starts the Merge Agent synchronously. For more information, see Synchronize a Pull Subscription.
4. Set a breakpoint in the business logic handler code, either in the method being debugged or in the class
constructor. For more information about the methods that can be implemented in a business logic handler,
see the BusinessLogicModule methods topic.
5. Build the business logic handler in debug mode and deploy the assembly and debugging symbol file (.pdb)
in the location registered in step 1.
NOTE
To simplify debugging, create a single Visual Studio .NET solution that contains both the business logic handler
project and the project that synchronizes the subscription. In this case, set the synchronization project as the startup
project, and configure the build environment to deploy the business logic assembly to the location registered in step
1 during debugging.
6. Execute insert, update, or delete commands against the subscription or publication database. The command
and execution location depends on the method being debugged.
7. Start the project from step 3 in debug mode to synchronize the subscription.
8. Assuming that no other breakpoints are set and the proper commands are replicated, the execution stops
when it reaches the breakpoint in the business logic handler.
To debug a business logic handler on a Web server using Web synchronization, or for a SQL Server Compact
Subscriber
1. Configure publishing and distribution, create a publication, and create a pull subscription to the publication.
The publication must support Web synchronization or SQL Server Compact Subscribers.
2. Create and register a business logic handler. For more information, see Implement a Business Logic Handler
for a Merge Article.
3. Set a breakpoint in the business logic handler code, either in the method being debugged or in the class
constructor. For more information about the methods that can be implemented in a business logic handler,
see the BusinessLogicModule methods topic.
4. Build the business logic handler in debug mode and deploy the assembly and debugging symbol file (.pdb)
at the Web server in the location registered in step 1.
NOTE
If the business logic handler fails to build because the assembly is in use, type the command iisreset on the Web
server at the command prompt to reset the Web server.
5. Synchronize the subscription with Web synchronization enabled. During synchronization, the Web server
loads the registered assembly.
6. Using the Visual Studio .NET debugger, attach to the one of the following processes on the Web server:
w3wp.exe - Windows Server 2003.
inetinfo.exe - Windows 2000 and Windows XP.
7. In the Output window, check the debug output to verify that the symbols for the registered assembly
loaded properly. If the symbols were not loaded, ensure that the correct .pdb file was copied in step 4, and
repeat step 5.
8. Execute insert, update, or delete commands against the subscription or publication database. The command
and execution location depends on the method being debugged.
9. Using the Visual Studio debugger, attach to the w3wp.exe process.
10. Synchronize the subscription again, using Web synchronization.
11. Assuming that no other breakpoints are set and the proper commands are replicated, the execution stops
when it reaches the breakpoint in the business logic handler.
See Also
Implement a Custom Conflict Resolver for a Merge
Article
Warehouse
This topic describes how to implement custom conflict resolver for a merge article in SQL Server 2017 by using
Transact-SQL or a COM-based custom resolver.
In This Topic
To implement custom conflict resolver for a merge article, using:
Transact-SQL
COM-based Resolver
Using Transact-SQL
You can write your own custom conflict resolver as a Transact-SQL stored procedure at each Publisher. During
synchronization, this stored procedure is invoked when conflicts are encountered in an article to which the resolver
was registered, and information on the conflict row is passed by the Merge Agent to the required parameters of
the procedure. Stored procedure-based custom conflict resolvers are always created at the Publisher.
NOTE
Microsoft SQL Server stored procedure resolvers are only invoked to handle row change-based conflicts. They cannot be
used to handle other types of conflicts such as insert failures due to PRIMARY KEY violations or unique index constraint
violations.
To create a stored procedure-based custom conflict resolver

1. At the Publisher in either the publication or msdb database, create a new system stored procedure that
implements the following required parameters:
PARAMETER DATA TYPE DESCRIPTION
@tableowner sysname Name of the owner of the table for

which a conflict is being resolved.
This is the owner for the table in the
publication database.
@tablename sysname Name of the table for which a conflict

is being resolved.
@rowguid uniqueidentifier Unique identifier for the row having

the conflict.
@subscriber sysname Name of the server from where a

conflicting change is being
propagated.
PARAMETER DATA TYPE DESCRIPTION
@subscriber_db sysname Name of the database from where

conflicting change is being
propagated.
@log_conflict OUTPUT int Whether the merge process should

log a conflict for later resolution:
0 = Do not log the conflict.
1 = Subscriber is the conflict loser.
2 = Publisher is the conflict loser.
@conflict_message OUTPUT nvarchar(512) Message to be given about the

resolution if the conflict is logged.
@destowner sysname The owner of the published table at

the Subscriber.
This stored procedure uses the values passed by the Merge Agent to these parameters to implement your
custom conflict resolution logic; it must return a single row result set that is identical in structure to the base
table and contains the data values for the winning version of the row.
2. Grant EXECUTE permissions on the stored procedure to any logins used by Subscribers to connect to the
Publisher.
To use a custom conflict resolver with a new table article
1. Execute sp_addmergearticle to define an article, specifying a value of MicrosoftSQL Server Stored Procedure
Resolver for the @article_resolver parameter and the name of the stored procedure that implements the
conflict resolver logic for the @resolver_info parameter. For more information, see Define an Article.
To use a custom conflict resolver with an existing table article
1. Execute sp_changemergearticle, specifying @publication, @article, a value of article_resolver for
@property, and a value of MicrosoftSQL Server Stored ProcedureResolver for @value.
2. Execute sp_changemergearticle, specifying @publication, @article, a value of resolver_info for
@property, and the name of the stored procedure that implements the conflict resolver logic for @value.
Using a COM-based Custom Resolver

The Microsoft.SqlServer.Replication.BusinessLogicSupport namespace implements an interface that enables you to
write complex business logic to handle events and resolve conflicts that occur during the merge replication
synchronization process. For more information, see Implement a Business Logic Handler for a Merge Article. You
can also write your own native code-based custom business logic to resolve conflicts. This logic is built as a COM
component and compiled into dynamic-link libraries (DLL), using products such as Microsoft Visual C++. Such a
COMbased custom conflict resolver must implement the ICustomResolver interface, which is designed
specifically for conflict resolution.
To create and register a COM-based custom conflict resolver
1. In a COM-compatible authoring environment, add references to the Custom Conflict Resolver library.
2. For a Visual C++ project, use the #import directive to import this library into your project.
3. Create a class that implements the ICustomResolver interface.
4. Implement certain methods and properties.
5. Build the project to create the custom conflict resolver library file.
6. Deploy the library in the directory containing the merge agent executable (usually \Microsoft SQL
Server\100\COM).
NOTE
A custom conflict resolver must be deployed at the Subscriber for a pull subscription, at the Distributor for a push
subscription, or at the Web server used with Web synchronization.
7. Register the custom conflict resolver library using regsvr32.exe from the deployment directory as follows:
regsvr32.exe mycustomresolver.dll
8. At the Publisher, execute sp_enumcustomresolvers (Transact-SQL) to verify that the library is not already
registered as a custom conflict resolver.
9. To register the library as a custom conflict resolver, execute sp_registercustomresolver (Transact-SQL), at
the Distributor. Specify the friendly name of the COM object for @article_resolver, the library's ID (CLSID)
for @resolver_clsid, and a value of false for @is_dotnet_assembly.
NOTE
When no longer needed, a custom conflict resolver can be unregistered using sp_unregistercustomresolver (Transact-
SQL).
10. (Optional) On a cluster, repeat steps 5-8 to register the custom resolver on all nodes of the cluster. This is
required to ensure that the custom resolver will be able to properly load the reconciler following a failover.
To use a custom conflict resolver with a new table article
1. At the Publisher, execute sp_enumcustomresolvers (Transact-SQL) and note the friendly name of the
desired resolver.
2. At the Publisher on the publication database, execute sp_addmergearticle (Transact-SQL) to define an article.
Specify the friendly name of the article resolver from step 1 for @article_resolver. For more information,
see Define an Article.
To use a custom conflict resolver with an existing table article
1. At the Publisher, execute sp_enumcustomresolvers (Transact-SQL) and note the friendly name of the
desired resolver.
2. Execute sp_changemergearticle (Transact-SQL), specifying @publication, @article, a value of
article_resolver for @property, and the friendly name of the article resolver from step 1 for @value.
See Also
COM-Based Custom Resolvers
Bulk-Load Data into Tables in a Merge Publication
Warehouse
When data is loaded into tables using the bcp Utility or the BULK INSERT command, by default, the merge
replication triggers that maintain tracking data in the MSmerge_contents system table are not fired. You can either
force the merge replication triggers to fire as the data is loaded, or you can insert the generated replication
metadata programmatically after the bulk copy operation using replication stored procedures.
To bulk-load data into tables published by merge replication using the bcp utility
1. At either the Publisher or Subscriber, execute the bcp Utility or BULK INSERT to insert data into a table
published using merge replication.
2. Use one of the following methods to ensure that replication metadata is generated for the inserted data.
Execute the bulk copy using the FIRE_TRIGGERS option.
On the database into which data was inserted, execute sp_addtabletocontents (Transact-SQL). Specify
the table name into which the data was inserted for @table_name.
Synchronize Data
Warehouse
Synchronizing data refers to the process of data and schema changes being propagated between the Publisher
and Subscribers after the initial snapshot has been applied at the Subscriber. Synchronization can occur:
Continuously, which is typical for transactional replication.
On demand, which is typical for merge replication.
On a schedule, which is typical for snapshot replication.
When a subscription is synchronized, different processes occur based on the type of replication you are
using:
Snapshot replication. Synchronization means that the Distribution Agent reapplies the snapshot at the
Subscriber so that schema and data at the subscription database is consistent with the publication
database.
If modifications to data or schema have been made at the Publisher, a new snapshot must be generated in
order to propagate modifications to the Subscriber.
Transactional replication. Synchronization means that the Distribution Agent transfers updates, inserts,
deletes, and any other changes from the distribution database to the Subscriber.
Merge replication. Synchronization means that the Merge Agent uploads changes from the Subscriber to
the Publisher and then downloads changes from the Publisher to the Subscriber. Conflicts, if any, are
detected and resolved. Data is converged, and the Publisher and all Subscribers eventually end up with the
same data values. If conflicts were detected and resolved, work that was committed by some of the users is
changed to resolve the conflict according to policies you define.
Snapshot publications completely refresh the schema at the Subscriber every time synchronization occurs,
so all schema changes are applied to the Subscriber. Transactional replication and merge replication also
support the most common schema changes. For more information, see Make Schema Changes on
Publication Databases.
To synchronize a push subscription, see Synchronize a Push Subscription.
To synchronize a pull subscription, see Synchronize a Pull Subscription.
To set synchronization schedules, see Specify Synchronization Schedules.
To view and resolve synchronization conflicts
SQL Server Management Studio: View and Resolve Data Conflicts for Merge Publications (SQL Server
Management Studio)
SQL Server Management Studio: View Data Conflicts for Transactional Publications (SQL Server
Management Studio)
Executing Code During Synchronization

Replication supports two methods of executing code during synchronization
On demand script execution is supported for transactional replication and merge replication. Using on
demand script execution you can specify a SQL script to run during synchronization. The script is copied to
the Subscriber and executed using sqlcmd at the beginning of the synchronization process. The script
does not have access to the replicated changes as they are applied to the Subscriber. For more
information, see Execute Scripts During Synchronization (Replication Transact-SQL Programming).
Business logic handlers are supported for merge replication. Using the business logic handler framework
you can write a managed code assembly that is called during the merge synchronization process. The
assembly includes business logic that can respond to a number of conditions during synchronization: data
changes, conflicts, and errors. For more information, see Execute Business Logic During Merge
Synchronization.
See Also
Detect and Resolve Merge Replication Conflicts
Warehouse
Transactional and merge replication allow you to validate that data at the Subscriber matches data at the
Publisher. Validation can be performed for specific subscriptions or for all subscriptions to a publication. Specify
one of the following validation types and the Distribution Agent or Merge Agent will validate data the next time it
runs:
Row count only. This validates whether the table at the Subscriber has the same number of rows as the
table at the Publisher, but does not validate that the content of the rows matches. Row count validation
provides a lightweight approach to validation that can make you aware of issues with your data.
Row count and binary checksum. In addition to taking a count of rows at the Publisher and Subscriber, a
checksum of all the data is calculated using the checksum algorithm. If the row count fails, the checksum is
not performed.
In addition to validating that data at the Subscriber and Publisher match, merge replication provides the
ability to validate that data is partitioned correctly for each Subscriber. For more information, see Validate
Partition Information for a Merge Subscriber.
To validate data
To validate all articles in a subscription, use SQL Server Management Studio, stored procedures or
Replication Management Objects (RMO). For more information, see Validate Data at the Subscriber. To
validate individual articles in snapshot and transactional publications, you must use stored procedures.
Data Validation Results

When validation is complete, the Distribution Agent or Merge Agent logs messages regarding success or failure
(replication does not report which rows failed). These messages can be viewed in SQL Server Management
Studio, Replication Monitor, and replication system tables. The how-to topic listed above demonstrates how to
run validation and view the results.
To handle validation failures, consider the following:
Configure the replication alert named Replication: Subscriber has failed data validation so that you
are notified of the failure. For more information, see Configure Predefined Replication Alerts (SQL Server
Management Studio).
Is the fact that validation failed an issue for your application? If the validation failure is an issue, manually
update the data so that it is synchronized, or reinitialize the subscription:
Data can be updated using the tablediff utility. For more information about using this utility, see
Compare Replicated Tables for Differences (Replication Programming).
For more information about reinitializaton, see Reinitialize Subscriptions.
Considerations for Data Validation

Take the following issues into consideration when validating data:
You must stop all update activity at Subscribers before validating data (it is not necessary to stop activity at
the Publisher when validation is occurring).
Because checksums and binary checksums can require large amounts of processor resources when
validating a large data set, you should schedule validation to occur when there is the least activity on the
servers used in replication.
Replication validates tables only; it does not validate whether schema only articles (such as stored
procedures) are the same at the Publisher and Subscriber.
Binary checksum can be used with any published table. Checksum cannot validate tables with column
filters, or logical table structures where column offsets differ (due to ALTER TABLE statements that drop or
add columns).
Replication validation uses the checksum and binary_checksum functions. For information about their
behavior, see CHECKSUM (Transact-SQL) and BINARY_CHECKSUM (Transact-SQL).
Validation by using binary checksum or checksum can incorrectly report a failure if data types are different
at the Subscriber than they are at the Publisher. This can occur if you do any one of the following:
Explicitly set schema options to map data types for earlier versions of SQL Server.
Set the publication compatibility level for a merge publication to an earlier version of SQL Server,
and published tables contain one or more data types that must be mapped for this version.
Manually initialize a subscription and are using different data types at the Subscriber.
Binary checksum and checksum validations are not supported for transformable subscriptions for
Validation is not supported for data replicated to non- SQL Server Subscribers.
How Data Validation Works

SQL Server validates data by calculating a row count or a checksum at the Publisher and then comparing those
values to the row count or checksum calculated at the Subscriber. One value is calculated for the entire
publication table and one value is calculated for the entire subscription table, but data in text, ntext, or image
columns is not included in the calculations.
While the calculations are performed, shared locks are placed temporarily on tables for which row counts or
checksums are being run, but the calculations are completed quickly and the shared locks removed, usually in a
matter of seconds.
When binary checksums are used, 32-bit redundancy check (CRC) occurs on a column-by-column basis rather
than a CRC on the physical row on the data page. This allows the columns with the table to be in any order
physically on the data page, but still compute to the same CRC for the row. Binary checksum validation can be
used when there are row or column filters on the publication.
See Also
Validate Partition Information for a Merge Subscriber
Warehouse
When you define a parameterized row filter for a merge publication, you use a function that references Subscriber
information, such as the Subscriber's login name. By default, replication validates Subscriber information based on
that function before each synchronization and whenever a snapshot is applied at the Subscriber. The validation
process ensures that data is partitioned correctly for each Subscriber. Validation behavior is controlled by the
validate_subscriber_info publication property, which can be changed using sp_changemergepublication
(Transact-SQL) or on the Subscription Options page of the Publication Properties dialog box. For more
information about changing publication properties, see View and Modify Publication Properties.
How Partition Validation Works

When a publication is filtered, for example, using the function SUSER_SNAME(), the Merge Agent applies the
initial snapshot to each Subscriber based on data that is valid for the SUSER_SNAME() expression.
If validation is enabled, when the Subscriber reconnects to the Publisher for the next synchronization, the Merge
Agent validates the information at the Subscriber and ensures that each Subscriber's partition is the same as the
one received in the initial snapshot. For each subsequent merge or snapshot application, the Merge Agent validates
each Subscriber's partition.
If the Merge Agent detects that the function used in the filtering expression returns a different value than it did at
the initial snapshot, the merge or snapshot application fails, and that Subscriber's subscription might require
reinitialization. Reinitialization might be necessary to prevent problems that can arise if the merge settings of a
Subscriber are changed, but it might be sufficient to change information at the Subscriber, such as the login name,
back to the value used at the time of the original snapshot.
When the Merge Agent validates a partition, in addition to validating the partition against the values returned by
any functions used in filtering expressions, the agent also checks whether the snapshot was generated prior to
changes that invalidate it, such as metadata cleanup operations or schema changes. If a partitioned snapshot is too
old, the Merge Agent will return an error and you must regenerate a partitioned snapshot for that Subscriber
based on a current regular snapshot.
See Also
Warehouse
This topic describes how to validate data at the Subscriber in SQL Server 2017 by using SQL Server Management
Validating data is a three-part process:
1. A single subscription or all subscriptions to a publication are marked for validation. Mark subscriptions for
validation in the Validate Subscription, Validate Subscriptions, and Validate All Subscriptions dialog
boxes, which are available from the Local Publications folder and the Local Subscriptions folder in
Microsoft SQL Server Management Studio. You can also mark subscriptions from the All Subscriptions
tab, the Subscription Watch List tab, and the publications node in Replication Monitor. For information
about starting Replication Monitor, see Start the Replication Monitor.
2. A subscription is validated the next time it is synchronized by the Distribution Agent (for transactional
replication) or the Merge Agent (for merge replication). The Distribution Agent typically runs continuously,
in which case validation occurs immediately; the Merge Agent typically runs on demand, in which case
validation occurs after you run the agent.
3. View the validation results:
In the detail windows in Replication Monitor: on the Distributor to Subscriber History tab for
transactional replication and the Synchronization History tab for merge replication.
In the View Synchronization Status dialog box in Management Studio.
In This Topic
Before you begin:
To validate data at the Subscriber, using:
Transact-SQL
Before You Begin

The procedures for Replication Monitor are for push subscriptions only because pull subscriptions cannot
be synchronized in Replication Monitor. However, you can mark a subscription for validation and view
validation results for pull subscriptions in Replication Monitor.
The validation results indicate whether validation succeeded or failed, but do not specify which rows failed
validation if a failure occurred. To compare data at the Publisher and Subscriber, use the tablediff Utility. For
more information about using this utility with replicated data, see Compare Replicated Tables for
Differences (Replication Programming).
To validate data for subscriptions to a transactional publication (Management Studio)
3. Right-click the publication for which you want to validate subscriptions, and then click Validate
Subscriptions.
4. In the Validate Subscriptions dialog box, select which subscriptions to validate:
Select Validate all SQL Server subscriptions.
Select Validate the following subscriptions, and then select one or more subscriptions.
5. To specify the type of validation to perform (row count, or row count and checksum) click Validation
Options, and then specify options in the Subscription Validation Options dialog box.
6. Click OK.
7. View validation results in Replication Monitor or the View Synchronization Status dialog box. For each
subscription:
a. Expand the publication, right-click the subscription, and then click View Synchronization Status.
b. If the agent is not running click Start in the View Synchronization Status dialog box. The dialog
box will display informational messages regarding validation.
If you do not see any messages regarding validation, the agent has already logged a subsequent
message. In this case, view the validation results in Replication Monitor. For more information, see
the Replication Monitor how to procedures in this topic.
To validate data for a single subscription to a merge publication (Management Studio)
3. Expand the publication for which you want to validate subscriptions, right-click the subscription, and then
click Validate Subscription.
4. In the Validate Subscription dialog box, select Validate this subscription.
5. To specify the type of validation to perform (row count, or row count and checksum) click Options, and
then specify options in the Subscription Validation Options dialog box.
6. Click OK.
7. View validation results in Replication Monitor or the View Synchronization Status dialog box:
b. If the agent is not running, click Start in the View Synchronization Status dialog box. The dialog
To validate data for all subscriptions to a merge publication (Management Studio)
3. Right-click the publication for which you want to validate subscriptions, and then click Validate All
Subscriptions.
4. In the Validate All Subscriptions dialog box, specify the type of validation to perform (row count, or row
count and checksum).
5. Click OK.
6. View validation results in Replication Monitor or the View Synchronization Status dialog box. For each
subscription:
b. If the agent is not running, click Start in the View Synchronization Status dialog box. The dialog
To validate data for all push subscriptions to a transactional publication (Replication Monitor)
2. Right-click the publication for which you want to validate subscriptions, and then click Validate
Subscriptions.
3. In the Validate Subscriptions dialog box, select which subscriptions to validate:
Select Validate all SQL Server subscriptions.
Select Validate the following subscriptions, and then select one or more subscriptions.
4. To specify the type of validation to perform (row count, or row count and checksum) click Validation
Options, and then specify options in the Subscription Validation Options dialog box.
5. Click OK.
7. View validation results. For each push subscription:
a. If the agent is not running, right-click the subscription, and then click Start Synchronizing.
b. Right-click the subscription, and then click View Details.
c. View information on the Distributor to Subscriber History tab in the Actions in the selected
session text area.
To validate data for a single push subscription to a merge publication (Replication Monitor)
publication.
3. Right-click the subscription you want to validate, and then click Validate Subscription.
4. In the Validate Subscription dialog box, select Validate this subscription.
5. To specify the type of validation to perform (row count, or row count and checksum) click Options, and
then specify options in the Subscription Validation Options dialog box.
6. Click OK.
8. View validation results:
c. View information on the Synchronization History tab in the Last message of the selected
session text area.
To validate data for all push subscriptions to a merge publication (Replication Monitor)
2. Right-click the publication for which you want to validate subscriptions, and then click Validate All
Subscriptions.
3. In the Validate All Subscriptions dialog box, specify the type of validation to perform (row count, or row
count and checksum).
4. Click OK.
6. View validation results. For each push subscription:
c. View information on the Synchronization History tab in the Last message of the selected
session text area.
Using Transact-SQL
To validate data for all articles in a transactional publication
1. At the Publisher on the publication database, execute sp_publication_validation (Transact-SQL). Specify
@publication and one of the following values for @rowcount_only:
1 - rowcount check only (the default)
2 - rowcount and binary checksum.
NOTE
When you execute sp_publication_validation (Transact-SQL), sp_article_validation (Transact-SQL) is executed for each
article in the publication. To successfully execute sp_publication_validation (Transact-SQL), you must have SELECT
permissions on all columns in the published base tables.
2. (Optional) Start the Distribution Agent for each subscription if it is not already running. For more
information, see Synchronize a Pull Subscription and Synchronize a Push Subscription.
3. Check the agent output for the result of the validation. For more information, see Validate Replicated Data.
To validate data for a single article in a transactional publication
1. At the Publisher on the publication database, execute sp_article_validation (Transact-SQL). Specify
@publication, the name of the article for @article, and one of the following values for @rowcount_only:
1 - Rowcount check only (the default)
2 - Rowcount and binary checksum.
NOTE
To successfully execute sp_article_validation (Transact-SQL), you must have SELECT permissions on all columns in the
published base table.
2. (Optional) Start the Distribution Agent for each subscription if it is not already running. For more
information, see Synchronize a Pull Subscription and Synchronize a Push Subscription.
3. Check the agent output for the result of the validation. For more information, see Validate Replicated Data.
To validate data for a single subscriber to a transactional publication
1. At the Publisher on the publication database, open an explicit transaction using BEGIN TRANSACTION
(Transact-SQL).
2. At the Publisher on the publication database, execute sp_marksubscriptionvalidation (Transact-SQL).
Specify the publication for @publication, the name of the Subscriber for @subscriber, and the name of
the subscription database for @destination_db.
3. (Optional) Repeat step 2 for each subscription being validated.
4. At the Publisher on the publication database, execute sp_article_validation (Transact-SQL). Specify
@publication, the name of the article for @article, and one of the following values for @rowcount_only:
1 - Rowcount check only (the default)
2 - Rowcount and binary checksum.
NOTE
To successfully execute sp_article_validation (Transact-SQL), you must have SELECT permissions on all columns in the
published base table.
5. At the Publisher on the publication database, commit the transaction using COMMIT TRANSACTION
(Transact-SQL).
6. (Optional) Repeat steps 1 through 5 for each article being validated.
7. (Optional) Start the Distribution Agent if it is not already running. For more information, see Synchronize a
Pull Subscription and Synchronize a Push Subscription.
8. Check the agent output for the result of the validation. For more information, see Validate Data at the
Subscriber.
To validate data in all subscriptions to a merge publication
1. At the Publisher on the publication database, execute sp_validatemergepublication (Transact-SQL). Specify
@publication and one of the following values for @level:
1 - Rowcount-only validation.
3 - Rowcount binary checksum validation.
This marks all subscriptions for validation.
2. Start the merge agent for each subscription. For more information, see Synchronize a Pull Subscription and
3. Check the agent output for the result of the validation. For more information, see Validate Data at the
Subscriber.
To validate data in selected subscriptions to a merge publication
1. At the Publisher on the publication database, execute sp_validatemergesubscription (Transact-SQL). Specify
@publication, the name of the Subscriber for @subscriber, the name of the subscription database for
@subscriber_db, and one of the following values for @level:
1 - Rowcount-only validation.
3 - Rowcount binary checksum validation.
This marks the selected subscription for validation.
2. Start the merge agent for each subscription. For more information, see Synchronize a Pull Subscription and
3. Check the agent output for the result of the validation.
4. Repeat steps 1 through 3 for each subscription being validated.
NOTE
A subscription to a merge publication can also be validated at the end of a synchronization by specifying the -Validate
parameter when running the Replication Merge Agent.
To validate data in a subscription using Merge Agent parameters

1. Start the Merge Agent at the Subscriber (pull subscription) or at the Distributor (push subscription) from
the command prompt in one of the following ways.
Specifying a value of 1 (rowcount) or 3 (rowcount and binary checksum) for the -Validate
parameter.
Specifying rowcount validation or rowcount and checksum validation for the -ProfileName
parameter.
For more information, see Synchronize a Pull Subscription or Synchronize a Push Subscription.

Replication enables you to use Replication Management Objects (RMO) to programmatically validate that data at
the Subscriber matches data at the Publisher. The objects you use depend on the type of replication topology.
Transactional replication requires validation of all subscriptions to a publication.
NOTE
For an example, see Example (RMO), later in this section.
To validate data for all articles in a transactional publication

2. Create an instance of the TransPublication class. Set the Name and DatabaseName properties for the
publication. Set the ConnectionContext property to the connection created in step 1.
3. Call the LoadProperties method to get the remaining properties of the object. If this method returns false,
either the publication properties in step 2 were defined incorrectly or the publication does not exist.
4. Call the ValidatePublication method. Pass the following:
ValidationOption
ValidationMethod
A Boolean that indicates whether to stop the Distribution Agent after validation is completed.
This marks the articles for validation.
5. If not already running, start the Distribution Agent to synchronize each subscription. For more information,
see Synchronize a Push Subscription or Synchronize a Pull Subscription. The result of the validation
operation is written to the agent history. For more information, see Monitoring Replication.
To validate data in all subscriptions to a merge publication
4. Call the ValidatePublication method. Pass the desired ValidationOption.
5. Run the Merge Agent for each subscription to start validation, or wait for the next scheduled agent run. For
more information, see Synchronize a Pull Subscription and Synchronize a Push Subscription. The result of
the validation operation is written to the agent history, which you view by using Replication Monitor. For
more information, see Monitoring Replication.
To validate data in a single subscription to a merge publication
4. Call the ValidateSubscription method. Pass the name of the Subscriber and subscription database being
validated and the desired ValidationOption.
5. Run the Merge Agent for the subscription to start validation, or wait for the next scheduled agent run. For
more information, see Synchronize a Pull Subscription and Synchronize a Push Subscription. The result of
the validation operation is written to the agent history, which you view by using Replication Monitor. For
more information, see Monitoring Replication.
Example (RMO )
This example marks all subscriptions to a transactional publication for rowcount validation.

try
{
conn.Connect();

// If we can't get the properties for this publication,

// throw an application exception.
{
// Initiate validataion for all subscriptions to this publication.
publication.ValidatePublication(ValidationOption.RowCountOnly,
ValidationMethod.ConditionalFast, false);
// If not already running, start the Distribution Agent at each

// Subscriber to synchronize and validate the subscriptions.
}
else
{
"Settings could not be retrieved for the publication. " +
"Ensure that the publication {0} exists on {1}.",
}
}
{
"Subscription validation could not be initiated.", ex);
}
finally
{
conn.Disconnect();
}

Try
conn.Connect()

' If we can't get the properties for this publication,

' throw an application exception.
' Initiate validataion for all subscriptions to this publication.

publication.ValidatePublication(ValidationOption.RowCountOnly, _
ValidationMethod.ConditionalFast, False)
' If not already running, start the Distribution Agent at each

' Subscriber to synchronize and validate the subscriptions.
Else
"Settings could not be retrieved for the publication. " + _
"Ensure that the publication {0} exists on {1}.", _
End If
"Subscription validation could not be initiated.", ex)
Finally
conn.Disconnect()
End Try
This example marks a specific subscription to a merge publication for rowcount validation.

try
{
conn.Connect();

// If we can't get the properties for this merge publication, then throw an application exception.
{
// Initiate validation of the specified subscription.
publication.ValidateSubscription(subscriberName,
subscriptionDbName, ValidationOption.RowCountOnly);
// Start the Merge Agent to synchronize and validate the subscription.

}
else
{
"Settings could not be retrieved for the publication. " +
"Ensure that the publication {0} exists on {1}.",
}
}
{
"The subscription at {0} to the {1} publication could not " +
"be validated.", subscriberName, publicationName), ex);
}
finally
{
conn.Disconnect();
}

Try
conn.Connect()

' If we can't get the properties for this merge publication, then throw an application exception.
' Initiate validation of the specified subscription.
publication.ValidateSubscription(subscriberName, _
subscriptionDbName, ValidationOption.RowCountOnly)
' Start the Merge Agent to synchronize and validate the subscription.
Else
"Settings could not be retrieved for the publication. " + _
"Ensure that the publication {0} exists on {1}.", _
End If
"The subscription at {0} to the {1} publication could not " + _
"be validated.", subscriberName, publicationName), ex)
Finally
conn.Disconnect()
End Try
Warehouse
All replication components in a topology should be scripted as part of a disaster recovery plan, and scripts can
also be used to automate repetitive tasks. A script contains the Transact-SQL system stored procedures necessary
to implement the replication component(s) scripted, such as a publication or subscription. Scripts can be created
in a wizard (such as the New Publication Wizard) or in Microsoft SQL Server Management Studio after you create
a component. You can view, modify, and run the script using SQL Server Management Studio or sqlcmd. Scripts
can be stored with backup files to be used in case a replication topology must be reconfigured.
A component should be re-scripted if any property changes are made. If you use custom stored procedures with
transactional replication, a copy of each procedure should be stored with the scripts; the copy should be updated if
the procedure changes (procedures are typically updated due to schema changes or changing application
requirements). For more information about custom procedures, see Specify How Changes Are Propagated for
Transactional Articles.
For merge publications that use parameterized filters, publication scripts contain the stored procedure calls to
create data partitions. The script provides a reference for the partitions created and a way in which to re-create
one or more partitions if necessary.
Example of Automating a Task with Scripts

Consider Adventure Works Cycles, which implements merge replication to distribute data to its remote sales
force. A sales representative downloads all the data that pertains to the customers in her territory using pull
subscriptions. When working offline, the sales representative updates data and enters new customers and orders.
Because Adventure Works Cycles has more than fifty sales representatives in different territories, it would be
time-consuming to create the different subscriptions at each Subscriber with the New Subscription Wizard.
Instead, the replication administrator can follow these steps:
1. Set up the necessary merge publications with partitions based on the sales representative or their territory.
2. Create a pull subscription for one Subscriber.
3. Generate a script based on that pull subscription.
4. Modify the script, changing such values as the name of the Subscriber.
5. Run the script at multiple Subscribers to generate the required pull subscriptions.
Script Replication Objects

Script replication objects from the replication wizards or from the Replication folder in Microsoft SQL Server
Management Studio. If you script from the wizards, you can choose to create objects and script them, or you can
choose only to script them.
IMPORTANT
All passwords are scripted as NULL. When possible, prompt users to enter security credentials at runtime. If you store
credentials in a script file, you must secure the file to prevent unauthorized access.
For more information about using the replication wizards, see:
To script an object from a replication wizard
1. On the Wizard Actions page of a wizard, select the check box appropriate for the wizard:
Generate a script file with steps to create a publication
Generate a script file with steps to create the subscription(s)
Generate a script file with steps to configure distribution
2. Specify options on the Script File Properties page.
3. Complete the wizard.
To script an object from Management Studio
1. Connect to the Distributor, Publisher, or Subscriber in Management Studio, and then expand the server
node.
2. Expand the Replication folder, and then expand the Local Publications folder or the Local
Subscriptions folder.
3. Right-click a publication or subscription, and then click Generate Scripts.
4. Specify options in the Generate SQL Script - <ReplicationObject> dialog box.
5. Click Script to File.
6. Enter a file name in the Script File Location dialog box, and then click Save. A status message is displayed.
7. Click OK, and then click Close.
To script multiple objects from Management Studio
1. Connect to the Distributor, Publisher, or Subscriber in Management Studio, and then expand the server
node.
2. Right-click the Replication folder, and then click Generate Scripts.
3. Specify options in the Generate SQL Script dialog box.
4. Click Script to File.
5. Enter a file name in the Script File Location dialog box, and then click Save. A status message is displayed.
6. Click OK, and then click Close.
Warehouse
This section contains links to technical reference documentation for SQL Server replication.
Errors and Events

Errors and Events Reference (Replication)
Feature Reference
More
Replication Agents
More
Replication Stored Procedures

sp_addarticle (Transact-SQL)
sp_adddistributiondb (Transact-SQL)
sp_adddistributor (Transact-SQL)
sp_addpublication (Transact-SQL)
sp_addsubscriber (Transact-SQL)
More
Replication Tables
MSmerge_conflicts_info (Transact-SQL)
MSpeer_response (Transact-SQL)
syssubscriptions (Transact-SQL)
More
Replication Views
syspublications (System View) (Transact-SQL)
syssubscriptions (System View) (Transact-SQL)
More
Replication Class Library

Microsoft.SqlServer.Replication
Microsoft.SqlServer.Replication.BusinessLogicSupport
See Also
Properties Reference (Replication)
Warehouse
This section of the documentation provides information on the following replication wizards and dialog boxes:
Replication Monitor
Microsoft Replication Conflict Viewer and Interactive Resolver
SQL Server Management Studio Replication Dialog Boxes
Warehouse
This section provides information on properties for the Distributor and the distribution database:
Distributor Properties, General
Distributor Properties, Publishers
Distribution Database Properties
See Also
Distributor Properties, General
Warehouse
The General page of the Distributor Properties dialog box allows you to add and delete distribution databases
and set distribution database properties.
The distribution database stores metadata and history data for all types of replication, and transactions for
transactional replication. In many cases, a single distribution database is sufficient. But if multiple Publishers use a
single Distributor, consider creating a distribution database for each Publisher. Doing so ensures that the data
flowing through each distribution database is distinct.
Options
Databases
The Databases property grid shows the name and retention properties of the distribution databases on the
Distributor. Transaction Retention is the length of time transactions are stored for transactional replication
(transaction retention is also known as distribution retention). History Retention is the length of time history
metadata is stored for all types of replication. For more information about distribution retention, see Subscription
Expiration and Deactivation.
Click the properties button (...) in the Databases property grid to launch the Distribution Database Properties
dialog box.
New
Click to create a new distribution database.
Delete
Select an existing distribution database in the Databases property grid, and click Delete to delete the database.
You cannot delete the distribution database if there is only one such database; each Distributor must have at least
one distribution database. To delete all distribution databases, you must disable distribution on the computer. For
more information, see Disable Publishing and Distribution.
Profile Defaults
Click to access replication agent profiles in the Agent Profiles dialog box. For more information about profiles, see
Replication Agent Profiles.
See Also
Distributor Properties, Publishers
Warehouse
The Publishers page of the Distributor Properties dialog box allows you to enable Publishers to use this
Distributor. You can also set properties associated with those Publishers. Be aware that enabling a Publisher to use
this server as its remote Distributor does not make that server a Publisher. You must connect to the Publisher,
configure it for publishing, and choose this server as the Distributor. You can configure the Publisher and choose a
Distributor through the New Publication Wizard.
Options
Publishers
Select the servers that are allowed to use this Distributor. Click the Properties button (...) next to a Publisher to view
and set additional properties.
Add
If the server you want to allow is not listed, click Add to add a Microsoft SQL Server Publisher or Oracle Publisher
to the list of available Publishers. If the server you add is the first server to use this Distributor as a remote
Distributor, you are prompted to provide an administrative link password.
Administrative link password
Use to specify or update the password for the connection replication makes between the Publisher and the remote
Distributor using the distributor_admin login:
If the Distributor serves only as a local Distributor, this password is randomly generated and automatically
configured.
If the Distributor already has a remote Publisher, a password was initially supplied on this page or the
Distributor Password page of the Configure Distribution Wizard.
If you enable the first remote Publisher for this Distributor, you are prompted to enter a password.
For more information on security for Distributors, see Secure the Distributor.
See Also
Distribution Database Properties
Warehouse
The Distribution Database Properties dialog box allows you to view a number of properties and to set the
transaction retention period and history retention period for the database.
Options
Name
The name of the distribution database, which defaults to 'distribution' (read-only).
File locations
The location of the database file and the log file (read-only).
Transaction retention period
Also known as the distribution retention period. The length of time transactions are stored for transactional
replication. For more information, see Subscription Expiration and Deactivation.
History retention period
The length of time history metadata is stored for all types of replication.
Queue Reader Agent security
The Queue Reader Agent is used by transactional replication with queued updating subscriptions. A Queue Reader
Agent is created automatically if you select Transactional publication with updating subscriptions on the
Publication Type page of the New Publication Wizard. Click Security Settings to change the account under
which the agent runs and makes connections to the Distributor.
A Queue Reader Agent can also be created by selecting Create Queue Reader Agent on this page (this option is
disabled if the agent has already been created).
Additional connection information for the Queue Reader Agent is specified in two places:
The agent connects to the Publisher using the credentials specified in the Publisher Properties dialog box,
which is available from the Publishers page of the Distributor Properties dialog box.
The agent connects to the Subscriber using the credentials specified for the Distribution Agent in the New
Subscription Wizard.
For more information, see Replication Agent Security Model.
See Also
Warehouse
This section contains information on Publisher properties available at the Distributor and the Publisher:
Publisher Properties - Distributor
Publisher Properties - Publisher, General
Publisher Properties - Publisher, Publication Databases
Publisher Properties - Publisher, Subscribers
See Also
Publisher Properties - Distributor
Warehouse
The Publisher Properties dialog box allows you to view and modify properties associated with the relationship
between the Publisher and its Distributor.
Options
Agent Connection to the Publisher
Specify the context under which the following agents make connections from the Distributor to the Publisher:
The Queue Reader Agent for transactional publications that allow queued updating subscriptions.
The Snapshot Agent and Log Reader Agent for Oracle publications.
Select Impersonate agent process account to make connections to the Publisher using the context of the
Microsoft Windows account under which these agents run, or specify SQL Server Authentication, and then
enter a value for Login and Password. It is recommended that you select Impersonate agent process
account. For more information on agent security, see Replication Agent Security Model.
The Windows accounts under which these agents run are specified in the New Publication Wizard. These
accounts can be changed:
In the Distributor Properties dialog box for the Queue Reader Agent.
In the Publication Properties dialog box for the Snapshot Agent and Log Reader Agent.
Miscellaneous
The properties Publisher Type and Distribution Database Name are read-only. The property Default
Snapshot Folder can be changed. For more information about the snapshot folder, see Secure the Snapshot
Folder.
See Also
Publisher Properties - Publisher, General
Warehouse
The General page of the Publisher Properties dialog box displays read-only information on the Distributor and
distribution database that the Publisher uses. To change the Distributor or distribution database for a Publisher:
1. Disable publishing on the Publisher. For more information, see Disable Publishing and Distribution.
2. Reconfigure publishing and distribution. For more information, see Configure Publishing and Distribution.
See Also
Publisher Properties - Publisher, Publication
Databases
Warehouse
The Publication Databases page of the Publisher Properties dialog box allows a user in the sysadmin fixed
server role to enable databases for replication. Enabling a database does not publish that database; rather, it allows
any user in the db_owner fixed database role for that database to create one or more publications on the database.
Options
Transactional
Select this check box to allow users in the db_owner fixed database role to create snapshot publications or
transactional publications in the database.
Merge
Select this check box to allow users in the db_owner fixed database role to create merge publications in the
database.
See Also
Publisher Properties - Publisher, Subscribers
Warehouse
The Subscribers page of the Publisher Properties dialog box is used for Publishers running versions of Microsoft
SQL Server prior to SQL Server 2005. The page allows you to enable Subscribers to receive data from publications
on this Publisher. Enabling a Subscriber to receive data from this Publisher does not create subscriptions to
publications on this Publisher. To create a subscription, you must use the New Subscription Wizard.
Options
Subscribers
The Subscribers property grid shows Subscribers that are enabled to receive data from publications on this
Publisher. Click the properties button (...) next to a Subscriber to view and set additional properties.
Add
Click Add to add a Subscriber, and then click Add SQL Server Subscriber or Add Non-SQL Server Subscriber.
See Also
Warehouse
The Subscriber Properties dialog box contains information relevant to Subscribers running versions of Microsoft
SQL Server before SQL Server 2005.
Options
Agent Connection to the Subscriber
The context under which the Distribution Agent and Merge Agent connect from the Distributor to the Subscriber
This applies only to versions before SQL Server 2005.
Select Impersonate agent process account to make connections to the Subscriber using the context of the SQL
Server Agent account at the Distributor, or specify SQL Server Authentication, and then enter a value for Login
and Password. Microsoft recommends that you select Impersonate agent process account.
For SQL Server 2005 and later versions, connection information is specified for each subscription in the New
Subscription Wizard and can be changed in the Subscription Properties dialog box.
Default Agent Schedules
The default schedule used in the New Subscription Wizard for Subscribers running versions of SQL Server before
SQL Server 2000.
Miscellaneous
Includes information on the Subscriber and Subscriber type.
See Also
Warehouse
This section provides information on all pages of the Publication Properties dialog box:
Publication Properties, General
Publication Properties, Articles
Publication Properties, Filter Rows
Publication Properties, Snapshot
Publication Properties, FTP Snapshot and Internet
Publication Properties, Subscription Options
Publication Properties, Publication Access List
Publication Properties, Agent Security
Publication Properties, Data Partitions
See Also
Publication Properties, General
Warehouse
The General page of the Publication Properties dialog box contains basic information on the publication,
including name, description, and the subscription expiration policy.
Options
Name
The name of the publication (read-only).
Database
The name of the publication database (read-only).
Description
The description of the publication.
Type
The type of publication (read-only).
Subscription expiration
Select one of the options for subscription expiration: Subscriptions never expire or Subscriptions expire, with
an explicit time period (Interval).
For snapshot and transactional publications, Microsoft recommends that you accept the default of Subscriptions
never expire.
For merge replication, Microsoft recommends that you accept the default of Subscriptions expire and set as low a
value as possible for Interval. As the subscription expiration period increases, so does the amount of metadata
stored, which can affect performance. Balance the need for Subscribers to be disconnected or simply not to
synchronize for an extended period against the potential performance issues of storing and processing a large
amount of metadata.
For more information, see Subscription Expiration and Deactivation.
Compatibility level
Microsoft SQL Server 2005 and later versions only; merge publications only. Select the minimum SQL Server
version required for Subscribers that synchronize with this publication. There are a number of rules associated with
determining the compatibility level.
See Also
Publication Properties, Articles
Warehouse
The Articles page of the Publication Properties dialog box: contains information about the articles contained in a
publication; allows you to add articles to and drop articles from existing publications; and allows you to change
article properties and column filtering.
NOTE
After a publication is created, some property changes require a new snapshot. If a publication has subscriptions, some
changes also require all subscriptions to be reinitialized. For more information, see Change Publication and Article Properties
and Add Articles to and Drop Articles from Existing Publications.
If you are publishing a database object that depends on one or more other database objects, you must publish all
referenced objects. For example, if you publish a view that depends on a table, you must publish the table also.
Objects that cannot be published have a red icon next to them, with an explanation in the information panel at the
bottom of the wizard page. The following objects cannot be published:
Encrypted objects.
Indexed views containing columns that allow NULL.
Tables without primary keys cannot be published in transactional publications.
Tables cannot be published in both a merge publication and a transactional publication enabled for queued
updating subscriptions. For more information about publishing an article in more than one publication, see
the "Publishing Tables in More Than One Publication" section in Publish Data and Database Objects.
Oracle Publishers
There are additional considerations for Oracle Publishers:
For a list of objects that can be published from Oracle, see Design Considerations and Limitations for Oracle
Publishers. Objects that cannot be published are not displayed.
For a list of data types that can be published, see Data Type Mapping for Oracle Publishers. Columns with
data types that cannot be published are not displayed.
Column Filters
Filter columns on this page by expanding a table in the Objects to publish pane and then selecting only the
columns required (rows can be filtered in the Filter Table Rows page of this wizard). Filtering columns is useful for
a number of reasons, including security (preventing sensitive data from being replicated) and performance
(avoiding replication of large binary large object (BLOB) columns, for example). For more information about
column filtering, including a list of column types that cannot be filtered, see Filter Published Data.
Options
The Objects to publish pane allows you to:
View all objects available for replication.
Add an article to a publication by selecting the check box next to that object.
Drop an article from a publication by clearing the check box next to that object. For information about when
articles can be dropped, see Add Articles to and Drop Articles from Existing Publications.
Include all objects of a particular type (such as a table) in the publication by selecting the check box next to
that object type (such as Tables).
Expand table nodes to see the columns in the table.
Filter table columns out of a publication by clearing the check box next to the column or include unpublished
columns by selecting the check box.
Right-click an object in the pane to see a menu of commands for that object.
Article Properties
Click Article Properties , and then click one of the following:
Click Set Properties of Highlighted <ObjectType> Article to launch the Article Properties -
<ObjectName> dialog box; property changes made in this dialog box are applied only to the object that is
highlighted in the object pane on the Articles page.
Click Set Properties of All <ObjectType> Articles, to launch the Properties for All <ObjectType>
Articles dialog box; property changes made in this dialog box are applied to all objects of that type in the
object pane on the Articles page, including ones not yet selected for publication.
NOTE
Property changes made in the Properties for All <ObjectType> Articles dialog box override any made previously
in the Article Properties - <ObjectName> dialog box. If, for example, you want to set a number of defaults for all
articles of an object type, but also want to set some properties for individual objects, set the defaults for all articles
first. Then set the properties for the individual objects.
Highlighted table is download-only

Merge replication only. Microsoft SQL Server 2005 and later versions only. Select to specify that changes are
disallowed at the Subscriber if a client subscription is used. Because download-only articles cannot be
updated at the Subscriber, tracking metadata is not sent to Subscribers. This can lead to reduced storage on
the Subscribers and a performance benefit, especially if the network connection is slow. This option
corresponds to a value of Download-only to Subscriber, prohibit Subscriber changes for the option
Synchronization direction in the Article Properties dialog box. For more information, see Optimize
Merge Replication Performance with Download-Only Articles.
Show only checked objects in the list
Select this check box to show only those articles that are selected in the object pane.
See Also
Publication Properties, Filter Rows
Warehouse
The Filter Rows page of the Publication Properties dialog allows you to add, edit, or delete:
Apply static row filters to table articles in snapshot, transactional, and merge publications.
Apply parameterized row filters to table articles in merge publications.
Use join filters to extend filters on merge table articles to related table articles.
For more information about filtering options, see Filter Published Data.
NOTE
Adding, editing, or deleting a filter requires a new snapshot for the publication and requires that all subscriptions be
reinitialized.
To maximize application performance and reduce the amount of remote storage required, or to restrict the
availability of certain data to specific Subscribers, you should publish only the data required. Your publication can
include both unfiltered and filtered tables. For example, you could include the complete (unfiltered) table of
company products and use row filters to provide a filtered table of customers for a specific region. By filtering
published data, you can:
Minimize the amount of data sent over the network.
Reduce the amount of storage space required at the Subscriber.
Customize publications and applications based on individual Subscriber requirements.
Avoid or reduce conflicts if Subscribers are updating data, because different data partitions can be sent to
different Subscribers (no two Subscribers will be updating the same data values).
Avoid transmitting sensitive data. Row filters and column filters can be used to restrict a Subscriber's access
to data. For merge replication, there are security considerations if you use a parameterized filter that
includes HOST_NAME(). For more information, see the section "Filtering with HOST_NAME()" in
Parameterized Row Filters.
Options
Filtered Tables
This pane is populated with filters as you add them to table articles in the publication. Tables with row filters are
shown as top-level nodes in the pane. For merge publications, tables to which filtering has been extended through
a join filter are shown as child nodes.
Add
Click Add to launch a dialog box that enables you to filter table articles. Clicking Add for a snapshot or
transactional publication launches a dialog box immediately. Clicking Add for a merge publication displays three
choices: Add Filter; Add Join to Extend the Selected Filter; Automatically Generate Filters.
Select Add Filter to launch the Add Filter dialog box. This dialog box allows you to apply row filters to a
table article. In the Add Filter dialog box, you could, for example, specify that a table with customer data
should only contain data on French customers when it is replicated to Subscribers.
Select Add Join to Extend the Selected Filter to launch the Add Join dialog box. The Add Join dialog box
allows you to extend a row filter so that it filters data in tables related to the table with the row filter. For
example, if a customer table is filtered so that it only contains data on French customers and there is a
related table for customer orders, you can define a join between the two tables so that the orders table only
includes orders from French customers.
NOTE
This option is available only if you first select the base table of the join in the filter pane.
Select Automatically Generate Filters to launch the Generate Filters dialog box. This dialog box allows
you to define a row filter on one table in a merge publication that replication automatically extends to other
tables that are related through foreign key relationships. For example, a publication could include three
tables: a customer table, an orders table (with a foreign key to the customer table), and an order details table
(with a foreign key to the orders table). Define a row filter on the customer table, and replication will extend
it to the other tables.
NOTE
When filters are automatically generated by replication, any existing filters on the publication are deleted. To include
both filters generated automatically and ones specified manually, generate filters first. You can only specify one set of
automatically generated filters for each publication.
Edit
Select a row filter or join filter in the filter pane and click Edit to launch the Edit Filter or Edit Join dialog
box.
Delete
Select a row filter or join filter in the filter pane and click Delete to delete the filter.
Find Table
Merge publications only. Click Find Table to find a table in a complex filter tree. In a database with complex
relationships, a table can be joined to multiple tables, and therefore can appear in more than one place in the
filter tree.
The actual table appears in only one place in the tree, and in other places, the table is represented by a
shortcut. A shortcut to a table is only a reference to the table; it does not show the child nodes of the table. A
shortcut node is marked with a shortcut arrow, and expanding that node shows the text Click Find Table to
see table for <tablename>.
Select a shortcut node in the pane and click Find Table The pane is expanded and the table is highlighted. If
you click Find Table without a shortcut node selected, a Find Table dialog box is launched.
Filter
Contains the Transact-SQL definition for the filter selected in the filter pane.
See Also
Join Filters
Publication Properties, Snapshot
Warehouse
The Snapshot page of the Publication Properties dialog box allows you to set the snapshot format, snapshot
folder location, and scripts to run before and after the application of the snapshot. The snapshot folder must be
designated as a share and have sufficient permissions for the agents that read and write files to the folder. For
more information about securing the folder appropriately, see Secure the Snapshot Folder.
NOTE
Changes require a new snapshot for the publication. For more information, see Change Publication and Article Properties.
Options
Snapshot format
Select native mode or character mode for the snapshot format.
Select Native SQL Server - all Subscribers must be servers running SQL Server if all Subscribers are
instances of Microsoft SQL Server other than Microsoft SQL Server Compact. The native snapshot format
provides the best performance.
Select Character - required if a Publisher or Subscriber is not running SQL Server if any Subscribers
are running SQL Server Compact or are non- SQL Server Subscribers.
Location of snapshot files
Select the location to store snapshot files. They can be stored in the default location; they can also be stored
in an alternate location instead of, or in addition to, the default location. Files stored in an alternate location
can be compressed.
Select Put files in the default folder to use the default snapshot folder for the Publisher. The snapshot
folder location is read-only in this dialog box, because it can only be changed for the Publisher in the
Distributor Properties dialog box. For more information, see Specify the Default Snapshot Location (SQL
Server Management Studio).
Select Put files in the following folder to specify an alternate location instead of, or in addition to, the
default location. Enter a path in the text box or click Browse and navigate to a location. Select Compress
snapshot files in this folder to compress the files in the alternate snapshot location. The alternate location
can be on another server, on a network drive, or on removable media such as a CD-ROM or removable disk.
For more information, see Alternate Snapshot Folder Locations and Compressed Snapshots.
Run additional scripts
Specify scripts to be executed before and after the snapshot is applied at the Subscriber. Scripts cannot be
specified if Snapshot format is Character.
Scripts are optional, but they provide a convenient way to execute commands and apply administrative
changes at Subscribers. For more information about executing scripts, see Execute Scripts Before and After
the Snapshot Is Applied.
Enter a path in the Before applying the snapshot, execute this script text box or click Browse to specify
a location for the script.
Enter a path in the After applying the snapshot, execute this script text box or click Browse to specify a
location for the script.
See Also
Publication Properties, FTP Snapshot and Internet
Warehouse
This page allows you to:
Set properties for delivering the snapshot through File Transfer Protocol (FTP). For more information, see
Transfer Snapshots Through FTP. To use FTP for snapshot delivery you must set up an FTP server. See the
Microsoft Windows documentation for more information.
NOTE
Changes to any FTP settings require a new snapshot to be generated.
Set properties for Web synchronization for merge replication on SQL Server 2005 and later versions, which
allows subscriptions to be synchronized over HTTPS (secure hypertext transfer protocol). To use Web
synchronization, you must configure an Microsoft Internet Information Services (IIS) server. For more
information, see Web Synchronization for Merge Replication.
Options
Access snapshot files via FTP
Select Allow Subscribers to download snapshot files using FTP (File Transfer Protocol), and specify FTP
server name, Port number, Path from the FTP root folder, Login, and Password, to allow Subscribers to use
FTP for snapshot delivery.
This option allows Subscribers to use FTP to retrieve snapshot files, but does not require them to do so. If you select
this option, the New Subscription Wizard defaults to having the Subscriber retrieve snapshot files through FTP. To
change the setting, use the Subscription Properties dialog box. If you allow Subscribers to access the snapshot
files through FTP, specify the FTP folder as the location for snapshot files on the Snapshot page of the Publication
Properties dialog box. Doing so will cause the Snapshot Agent to update the files in the FTP folder automatically
when a new snapshot is generated. If the location is not set to the FTP folder, you will have to update the files
manually when new snapshots are generated. For more information, see Deliver a Snapshot Through FTP.
Web Synchronization
Merge replication only. Select Allow Subscribers to synchronize by connecting to a Web server, and specify a
Web server address to allow merge Subscribers to use Web synchronization. The Web server must use Secure
Sockets Layer (SSL), and the Web address must be fully qualified, such as https://server.domain.com/synchronize .
For more information, see Configure Web Synchronization.
See Also
Publication Properties, Subscription Options
Warehouse
The Subscription Options page of the Publication Properties dialog box allows you to view and set publication
level properties associated with subscriptions. The properties are grouped into the following categories:
Properties that apply to all publications.
Properties that apply to snapshot and transactional publications (including those that allow updating
subscriptions).
Properties that apply to merge publications.
NOTE
Some properties are read-only; the reasons are covered in the property descriptions in this topic. Some property changes
require a new snapshot for the publication, and some also require that all subscriptions be reinitialized. For more information,
see Change Publication and Article Properties.
Options for all publications

Creation and Synchronization
Allow anonymous subscriptions
Determines whether to allow anonymous pull subscriptions. Anonymous subscriptions are supported for Microsoft
SQL Server Compact 3.5 Service Pack 1, Microsoft SQL Server 2005 Mobile Edition, and Microsoft SQL Server for
Windows CE. To use this option for snapshot and transactional publications, the option Snapshot always
available must be set to True.
Attachable subscription database
Determines whether subscriptions can be created by attaching a copy of a subscription database (requires that the
option Snapshot always available is set to True for snapshot and transactional publications).
IMPORTANT
Attachable subscriptions will not be available in a future release. The feature is deprecated.
Allow pull subscriptions

Determines whether to allow Subscribers to create pull subscriptions to this publication. For more information, see
Subscribe to Publications.
Schema Replication
Replicate schema changes
Microsoft SQL Server 2005 and later versions only. Determines whether to replicate schema changes (such as
adding a column to a table or changing the data type of a column) to published objects. For more information, see
Make Schema Changes on Publication Databases.
Options for snapshot and transactional publications

Creation and Synchronization
Independent Distribution Agent
Determines whether to use an agent that is independent of other publications from this database. This option is
read-only; it is set to True by default for publications created with the New Publication Wizard and cannot be
changed after the publication is created. For more information, see Replication Agent Administration.
Snapshot always available
Determines whether snapshot files are created every time the Snapshot Agent runs (requires Independent
Distribution Agent). This option is read-only; it is set to True if you select Create a snapshot immediately and
keep the snapshot available to initialize subscriptions on the Snapshot Agent page of the New Publication
Wizard (the default). For more information, see Create and Apply the Snapshot.
Allow initialization from backup files
SQL Server 2005 and later versions only. Determines whether to allow backup files to be used to initialize
subscriptions. For more information, see Initialize a Transactional Subscription Without a Snapshot.
Allow non-SQL Server Subscribers
SQL Server 2005 and later versions only. Determines whether the publication supports non- SQL Server
Subscribers. Setting this option to True sets other publication properties to support non- SQL Server Subscribers.
This option is read-only if subscriptions exist; it cannot be set to True if Allow immediate updating
subscriptions, Allow queued updating subscriptions, or Allow peer-to-peer subscriptions is set to True. For
more information, see Non-SQL Server Subscribers.
Data Transformation
Allow data transformations
Determines whether to use Data Transformation Services (DTS) to transform data before distributing it to a
Subscriber. This option is read-only; data transformations can be enabled only if a publication is created using
stored procedures.
IMPORTANT
Transformable subscriptions will not be available in a future release. The feature is deprecated.
Peer-to -Peer Replication

Allow peer-to-peer subscriptions
Applies to only SQL Server 2005 and later versions. Determines whether the publication supports peer-to-peer
replication. Setting this option to True sets other publication properties to support peer-to-peer replication. This
option is read-only if subscriptions exist. This option cannot be set to True if Allow immediate updating
subscriptions or Allow queued updating subscriptions, or Allow non-SQL Server Subscribers is set to True.
For more information, see Peer-to-Peer Transactional Replication.
Allow peer-to-peer conflict detection
Applies to only SQL Server 2008 and later versions. Specifies whether conflict detection is enabled for this
publication. To use conflict detection, all nodes must be running SQL Server 2008 or a later version; and detection
must be enabled for all nodes. To use conflict detection, you must also specify a value for Peer originator id. For
more information, see Conflict Detection in Peer-to-Peer Replication.
Peer originator id
Applies to only SQL Server 2008 and later versions. Specifies an ID for a node in a peer-to-peer topology. This ID is
used for conflict detection if Allow peer-to-peer conflict detection is set to True. Specify a positive, nonzero ID
that has never been used in the topology. For a list of IDs that have already been used, query the
Mspeer_originatorid_history system table.
Updatable Subscriptions
Allow immediate updating subscriptions
Determines whether Subscriber data changes can be immediately replicated to the Publisher. This option is read-
only; updating subscriptions can be enabled only when a publication is created. For more information, see
Updatable Subscriptions for Transactional Replication.
Allow queued updating subscriptions
Determines whether Subscriber data changes can be queued and replicated to the Publisher at a later time. This
option is read-only; updating subscriptions can be enabled only when a publication is created. For more
information, see Updatable Subscriptions for Transactional Replication.
Report conflicts centrally
Determines whether to report conflicting data changes only at the Publisher or at both the Publisher and the
Subscriber (requires the option Allow queued updating subscriptions). This option is read-only; it is set to True
by default for publications created with the New Publication Wizard and cannot be changed after the publication is
created. A value of True means conflicts are reported only at the Publisher. Conflicts can be viewed only where
they are reported.
Conflict resolution policy
Specifies the action to take when a Subscriber change conflicts with a Publisher change (requires the option Allow
queued updating subscriptions). For more information, see Queued Updating Conflict Detection and Resolution.
Queue type
Determines whether to use a SQL Server queue or Microsoft Message Queuing (MSMQ) to queue changes at the
Subscriber until they can be applied to the Publisher (requires the option Allow queued updating
subscriptions). This option is relevant only for SQL Server 2000; later versions always use SQL Server tables for
queuing.
Options for merge publications

Conflict Reporting
Report conflicts centrally
Determines whether to report conflicting data changes only at the Publisher or at both the Publisher and the
Subscriber. This option is read-only; it is set to True by default for publications created with the New Publication
Wizard and cannot be changed after the publication is created. A value of True means conflicts are reported only at
the Publisher. Conflicts can be viewed only where they are reported. For more information, see the "Viewing
Conflicts" section of Advanced Merge Replication Conflict Detection and Resolution.
Filtering
Allow parameterized filters
Set based on whether a publication uses parameterized filters. This option is always read-only. For more
information, see Parameterized Row Filters.
Validate Subscribers
Determines which functions to use when validating that a Subscriber has the correct partition of data. Separate
multiple values by commas. For more information, see Validate Partition Information for a Merge Subscriber.
Precompute partitions
SQL Server 2005 and later versions only. Determines whether to optimize synchronization by computing in
advance which data rows belong in which partitions. This setting defaults to True if the publication meets the
criteria for precomputed partitions. For more information, see Optimize Parameterized Filter Performance with
Precomputed Partitions.
Optimize synchronization
Determines whether to optimize merge processing by storing additional metadata at each Subscriber. This
optimization has been superseded by precomputed partitions; the Optimize synchronization option is only
relevant if Precompute partitions is set to False. For more information, see Parameterized Row Filters.
Merge Processes
Limit concurrent processes
Determines whether to limit the number of Merge Agents that can run at the same time. This is typically used if a
publication has lots of push subscriptions that might be synchronizing at the same time.
Maximum concurrent processes
The maximum number of Merge Agents that can run at the same time (requires Limit concurrent processes). If
the number of agents synchronizing exceeds the maximum, agents are put in a queue until the number drops
under the maximum.
See Also
Publication Properties, Publication Access List
Warehouse
The Publication Access List page of the Publication Properties dialog box allows you to add and remove logins,
accounts, and groups from the publication access list (PAL). The PAL is the primary mechanism for securing the
Publisher. When you create a publication, replication creates a PAL for the publication. The PAL, which functions
similarly to a Microsoft Windows access control list, contains a list of logins, accounts, and groups that are granted
access to the publication.
When a Subscriber connects to the Publisher or Distributor and requests access to a publication, the login of the
Subscriber is compared against the authentication information in the PAL. This provides additional security for the
Publisher by preventing the Publisher and Distributor login from being used by a client tool to perform
modifications on the Publisher directly. For more information, see Secure the Publisher.
Options
Add
Add a new entry to the list. You can add only those login, account, or group names that are already defined at both
the Publisher and Distributor. They are defined at both servers if domain accounts are used or local accounts have
been created at both servers.
Remove
Remove the selected entry from the list.
Remove All
Remove all entries from the list.
See Also
Publication Properties, Agent Security
Warehouse
The Agent Security page of the Publication Properties dialog box allows you to access the settings for the
accounts under which the following agents run and make connections to the computers in a replication topology:
The Snapshot Agent for all publications.
The Log Reader Agent for all transactional publications. There is one Log Reader Agent for each database
published for transactional replication. Changing the Log Reader Agent settings affects all transactional
publications in a database.
The Queue Reader Agent for transactional publications that allow queued updating subscriptions. There is
one Queue Reader Agent for each distribution database. Changing the Queue Reader Agent settings affects
all transactional publications with queued updating subscriptions that use the same distribution database.
For more information about Queue Reader Agent security settings, see View and Modify Replication Security
Settings.
For more information about security settings and the permissions required by each agent, see Replication
Agent Security Model.
Options
Security settings or Create Agent
If an agent job has been created, click Security settings to access a dialog box that allows you to change the
security settings for an agent. If an agent job has not been created, click Create Agent to create one and specify
security settings.
See Also
Publication Properties, Data Partitions
Warehouse
The Data Partitions page of the Publication Properties dialog box allows you to define data partitions for merge
publications that use parameterized filtering. After defining partitions, you can then generate snapshots for these
partitions, providing different initial data sets for different Subscribers based on the connection properties (login
and/or computer name) of the Subscribers. You can also select to allow Subscribers to request snapshot delivery
and generation if they do not have a snapshot available for their partition the first time they synchronize. For more
information, see Create a Snapshot for a Merge Publication with Parameterized Filters.
Options
Add
Click Add to define a partition. In the Add Data Partition dialog box, specify values for HOST_NAME() and/or
SUSER_SNAME(), and define a schedule to refresh snapshots.
Edit
Select an existing partition in the grid, and click Edit to edit the partition.
Delete
Select an existing partition in the grid, and click Delete to delete the partition.
Generate the selected snapshots now
Select one or more partitions in the grid, and click Generate the selected snapshots now to generate snapshots
for these partitions.
Clean up the existing snapshots
Select one or more partitions in the grid, and click Clean up the existing snapshots to clean up snapshots for
these partitions.
Automatically define a partition and generate a snapshot if needed when a new Subscriber tries to
synchronize
Select this option if you want to allow Subscribers to request snapshot generation and application. Subscribers
might require this option if they do not have a snapshot available for their partition the first time they synchronize.
See Also
Warehouse
The Article Properties dialog box is available from the New Publication Wizard and the Publication Properties
dialog box. It allows you to view and set properties for all types of articles. Some properties can be set only when
the publication is created, and others can be set only if the publication has no active subscriptions. Properties that
cannot be set are displayed as read-only.
NOTE
After a publication is created, some property changes require a new snapshot. If a publication has subscriptions, some
changes also require all subscriptions to be reinitialized. For more information, see Change Publication and Article Properties.
Each property in the Article Properties dialog box includes a description. Click a property, and its description is
displayed at the bottom of the dialog box. This topic provides additional information on a number of properties.
The properties are grouped into the following categories:
Properties that apply to all SQL Server publications.
Properties that apply to transactional publications from SQL Server.
Properties that apply to merge publications.
Properties that apply to transactional and snapshot publications from Oracle Publishers.
Options for all publications

Copy table partitioning schemes and Copy index partitioning schemes
SQL Server 2005 introduced table partitioning and index partitioning, which are unrelated to the partitioning
replication offers through row and column filters. The Copy table partitioning schemes and Copy index
partitioning schemes options specify whether partitioning schemes should be copied to the Subscriber. For more
information about partitioning, see Partitioned Tables and Indexes.
Convert data types
Determines whether to convert from user-defined data types to base data types when creating objects at the
Subscriber. User-defined data types include the user-defined CLR types introduced in SQL Server 2005. Specify a
value of True if you will replicate these data types to previous versions of SQL Server; this ensures they can be
handled properly at the Subscriber.
Create schemas at Subscriber
SQL Server 2005 introduced schemas, which are defined using the CREATE SCHEMA statement. A schema is the
owner of an object; it is used in a multi-part name, such as <Database>.<Schema>.<Object>. If you have objects in
the database owned by schemas other than DBO, replication can create these schemas at the Subscriber, so that
published objects can be created.
If you will replicate data to versions of SQL Server prior to SQL Server 2005:
Set this option to False, because previous versions do not support CREATE SCHEMA.
For each schema, add a user to the subscription database with the same name as the schema.
Convert XML to NTEXT, Convert MAX data types to NTEXT and IMAGE, Convert new datetime to
NVARCHAR, Convert filestream to MAX data types, Convert large CLR to MAX data types, Convert
hierarchyId to MAX data types, and Convert spatial to MAX data types.
Determines whether to convert the data types and attributes as described. Specify a value of True if you will
replicate these data types to earlier versions of SQL Server. This ensures they can be handled properly at the
Subscriber.
Destination object name
The name of the object created in the subscription database. This option cannot be changed for articles in
publications that are enabled for peer-to-peer transactional replication.
Destination object owner
The schema under which the object is created in the subscription database. The default is the schema to
which the object belongs in the publication database, with the following exceptions:
For articles in merge publications with a compatibility level lower than 90: by default, the owner is left blank
and is specified as dbo during the creation of the object on the Subscriber.
For articles in Oracle publications: by default, the owner is specified as dbo.
For articles in publications that use character mode snapshots (which are used for non- SQL Server
Subscribers and SQL Server Compact Subscribers): by default, the owner is left blank. The owner defaults to
the owner associated with the account used by the Distribution Agent or Merge Agent to connect to the
Subscriber.
This option cannot be changed for articles in publications that are enabled for peer-to-peer transactional
replication.
Automatically manage identity ranges
Replication, by default, manages all identity columns at the Publisher and each Subscriber. Each replication
node is assigned a range of identity values (specified with the Publisher range size and Subscriber range
size options) to ensure that a given value is used at only one node. For more information, see Replicate
Identity Columns.
Options for transactional publications

Copy INSERT, UPDATE, and DELETE stored procedures
If, in the Statement Delivery section of this dialog box, you select to use stored procedures to propagate changes
to Subscribers (the default), select whether to copy the procedures to each Subscriber. If you select False, you must
copy the procedures manually, or the Distribution Agent will fail when attempting to deliver changes.
Statement delivery
The options in this section apply to all tables, including indexed views that are replicated as tables. Microsoft
recommends that you use the default options unless your application requires different functionality. By default,
transactional replication propagates changes to Subscribers through a set of stored procedures that are installed
on each Subscriber. When an insert, update, or delete occurs on a table at the Publisher, the operation is translated
into a call to a stored procedure at the Subscriber.
The delivery statement options specify whether to use a stored procedure, and if so, which format should be
used for parameters passed to the procedure. The stored procedure options allow you to use the procedures that
replication automatically creates or substitute custom procedures you have created.
For more information, see Specify How Changes Are Propagated for Transactional Articles.
Replicate
This option applies to store procedures only. It determines whether to replicate the definition of the stored
procedure (the CREATE PROCEDURE statement) or its execution. If you replicate the execution of the procedure, the
procedure definition is replicated to the Subscriber when the subscription is initialized; when the procedure is
executed at the Publisher, replication executes the corresponding procedure at the Subscriber. This can provide
significantly better performance for cases where large batch operations are performed. For more information, see
Publishing Stored Procedure Execution in Transactional Replication.
Options for merge publications

The Article Properties dialog box for merge publications has two tabs: Properties and Resolver.
Properties tab
Synchronization direction
Determines whether changes can be uploaded from Subscribers that use the client subscription type:
Bidirectional (the default): changes can be downloaded to the Subscriber and uploaded to the Publisher.
Download-only to Subscriber, prohibit Subscriber changes: changes can be downloaded to the
Subscriber, but they cannot be uploaded to the Publisher. Triggers prevent changes from being made at the
Subscriber.
Download-only to Subscriber, allow Subscriber changes: changes can be downloaded to the
Subscriber, but they cannot be uploaded to the Publisher.
For more information, see Optimize Merge Replication Performance with Download-Only Articles.
Partition options
Specifies the type of partitions that a parameterized filter creates. For more information, see the "Setting
'partition options'" section of Parameterized Row Filters.
Tracking level
Determines whether to treat changes to the same row or to the same column as a conflict.
Verify INSERT permission, Verify UPDATE permission, and Verify DELETE permission
Determines whether to check during synchronization that the Subscriber login has INSERT, UPDATE, or
DELETE permissions on the published tables in the publication database. The default is False because merge
replication does not require these permissions to be granted; access to the published tables is controlled
through the Publication Access List (PAL). For more information about the PAL, see Secure the Publisher.
You can require permissions to be checked if you want to allow one or more Subscribers to upload some
changes to published data, but not others. For example, you could add a Subscriber to the PAL, but not give
the Subscriber any permissions on the tables in the publication database. You could then set Verify DELETE
permissions to True: the Subscriber would be able to upload inserts and updates, but not deletes.
Multicolumn UPDATE
When merge replication performs an update, it updates all changed columns in one UPDATE statement and
resets unchanged columns to their original values. The alternative in these cases is to issue multiple UPDATE
statements, with one UPDATE statement for each column that has changed. The multicolumn UPDATE
statement is typically more efficient, but you should consider setting the option to False if triggers on the
table are set to respond to updates of certain columns, and they respond inappropriately because those
columns are reset when updates occur.
IMPORTANT
This option is deprecated and will be removed in a future release.
Resolver tab
Use the default resolver
If you select the default resolver, conflicts are resolved based on the priority assigned to each Subscriber or the first
change written to the Publisher, depending on the type of subscriptions used. For more information, see Detect and
Resolve Merge Replication Conflicts.
Use a custom resolver (registered at the Distributor)
If you choose to use an article resolver (either one supplied by Microsoft or one you have written), you must select
a resolver from the list-box. For more information, see Advanced Merge Replication Conflict Detection and
Resolution.
If the resolver requires any input, specify it in Enter information needed by the resolver text box. For more
information about input required by Microsoft custom resolvers, see Microsoft COM-Based Resolvers.
Allow Subscriber to resolve conflicts interactively during on-demand synchronization
Select this option if Subscribers will use on-demand synchronization (the default for merge replication) and you
want to resolve conflicts interactively. Specify on-demand synchronization on the Synchronization Schedule
page of the New Subscription Wizard. To resolve conflicts interactively, use the Interactive Resolver user interface.
For more information, see Interactive Conflict Resolution.
Require verification of a digital signature before merging
All COM-based resolvers supplied by Microsoft are signed. Select this option to verify that the resolver is valid
when synchronizing.
Options for Oracle publications

The Article Properties dialog box for Oracle publications has two tabs: Properties and Data Mapping. Oracle
publications do not support all of the properties that SQL Server publications support. For more information, see
Design Considerations and Limitations for Oracle Publishers.
Properties tab
Copy INSERT, UPDATE, and DELETE stored procedures
If the article is in a transactional publication and, in the Statement Delivery section of this dialog box, you select
to use stored procedures to propagate changes to Subscribers (the default), select whether to copy the procedures
to each Subscriber. If you select False, you must copy the procedures manually, or the Distribution Agent will fail
when attempting to deliver changes.
Destination object owner
If you enter a value other than dbo:
For Subscribers running SQL Server 2005 or later, you must ensure that a schema is created at the
Subscriber with the same name as the value you enter. For more information, see CREATE SCHEMA
(Transact-SQL).
For Subscribers running versions prior to SQL Server 2005, for each schema, add a user to the subscription
database with the same name as the schema.
Tablespace name
The tablespace in which to create the replication change tracking tables on the Oracle server instance. For
more information, see Manage Oracle Tablespaces.
Statement delivery
The options in this section apply to all tables in transactional publications. Microsoft recommends that you
use the default options unless your application requires different functionality. By default, transactional
replication propagates changes to Subscribers through a set of stored procedures that are installed on each
Subscriber. When an insert, update, or delete occurs on a table at the Publisher, the operation is translated
into a call to a stored procedure at the Subscriber.
The delivery statement options specify whether to use a stored procedure, and if so, which format should
be used for parameters passed to the procedure. The stored procedure options allow you to use the
procedures that replication automatically creates or substitute custom procedures you have created.
For more information, see Specify How Changes Are Propagated for Transactional Articles.
Data Mapping tab
Column name
The name of the column at the Publisher (read-only).
Publisher data type
The Oracle data type for the column at the Publisher (read-only). The data type can only be changed directly in the
Oracle database. For more information, see the Oracle documentation.
Subscriber data type
The SQL Server data type to which the Oracle data type is mapped when data is replicated:
For some data types there is only one possible mapping, in which case the column in the property grid is
read-only.
For some types, there is more than one type that you can select. Microsoft recommends that you use the
default mapping unless your application requires a different mapping. For more information, see Data Type
Mapping for Oracle Publishers.
See Also
Warehouse
This section provides information on the Subscription Properties dialog box:
Subscription Properties - Subscriber covers subscription properties available at the Subscriber (pull
subscriptions only).
Subscription Properties - Publisher covers subscription properties available at the Publisher (pull and push
subscriptions).
See Also
Subscription Properties - Subscriber
Warehouse
The Subscription Properties dialog box at the Subscriber allows you to view and set properties for pull
subscriptions.
Each property in the Subscription Properties dialog box includes a description. Click a property to see its
description displayed at the bottom of the dialog box. This topic provides additional information on a number of
properties. The properties are grouped into the following categories:
Properties that apply to all subscriptions.
Properties that apply to transactional subscriptions.
Properties that apply to merge subscriptions.
If an option is displayed as read-only, it can only be set when the subscription is created. If you want to set
options that are not available in the New Subscription Wizard, create the subscription with stored
procedures. For more information, see Create a Pull Subscription and Create a Push Subscription.
NOTE
If a Distribution Agent or Merge Agent job has not yet been created for the subscription, many subscription properties are
not displayed. To create an agent job for a pull subscription, Execute sp_addpullsubscription_agent (Transact-SQL) (for a
subscription to a snapshot or transactional publication) or sp_addmergepullsubscription_agent (Transact-SQL) (for a
subscription to a merge publication).
Options for all subscriptions

Initialize published data from a snapshot
Determines whether subscriptions are initialized with a snapshot (the default) or through another method. For
more information on initializing subscriptions, see Initialize a Subscription.
Snapshot location
Determines the location from which snapshot files are accessed during initialization or reinitialization. The location
can be one of the following values:
Default location: the default location, which is defined when configuring a Distributor. For more
information, see Specify the Default Snapshot Location (SQL Server Management Studio).
Alternate folder: an alternate location, which can be specified in the Publication Properties dialog box.
For more information, see Alternate Snapshot Folder Locations.
Dynamic snapshot folder: a snapshot location for merge publications that use parameterized row filters.
For more information, see Snapshots for Merge Publications with Parameterized Filters.
FTP folder: a folder accessible to a File Transfer Protocol (FTP) server. For more information, see Transfer
Snapshots Through FTP.
Snapshot folder
If you select any value other than Default location for the Snapshot Location option, you must specify a
path to the snapshot folder.
Use Windows Synchronization Manager
Determines whether this subscription can be synchronized using Microsoft Windows Synchronization
Manager.
Security
Click the Agent process account row, and then click the properties button (...) to change the account under
which the Distribution Agent or Merge Agent runs at the Subscriber. The security options related to
connections depend on the type of subscription:
For subscriptions to a transactional publication: to change the account under which the Distribution Agent
makes connections to the Distributor, click Distributor Connection, and then click the properties button
(...).
For immediate updating subscriptions to a transactional publication: in addition to the Distributor
connection described above, you can change the method used to propagate changes from the Subscriber to
the Publisher: click Publisher Connection, and then click the properties button (...).
For subscriptions to merge publications click Publisher Connection, and then click the properties button
(...).
For more information about the permissions required for each agent, see Replication Agent Security Model.
Options for transactional subscriptions

Updatable subscription
Determines whether Subscriber changes are replicated back to the Publisher. Changes can be replicated using
queued updating or immediate updating. The option Subscriber update method determines which method to
use. For more information, see Updatable Subscriptions for Transactional Replication.
Options for merge subscriptions

Partition definition (HOST_NAME)
For a publication that uses parameterized filters, merge replication evaluates one of two system functions (or both
if the filter references both functions) during synchronization to determine the data that a Subscriber should
receive: SUSER_SNAME() or HOST_NAME(). By default, HOST_NAME() returns the name of the computer on
which the Merge Agent is running, but you can override this value in the New Subscription Wizard. For more
information on parameterized filters and overriding HOST_NAME(), see Parameterized Row Filters.
Subscription type and Priority
Displays whether the subscription is a client or server subscription (this cannot be changed after the subscription
has been created). Server subscriptions can republish data to other Subscribers and can be assigned a priority for
conflict resolution.
If you selected a subscription type of server in the New Subscription Wizard, the Subscriber is given a priority that
is used during conflict resolution
Resolve conflicts interactively
Determines whether to use the Interactive Resolver user interface to resolve conflicts during merge
synchronization. This requires a value of Enable for Use Windows Synchronization Manager. For more
information, see Interactive Conflict Resolution.
Web Synchronization
Use Web Synchronization determines whether to connect to a Microsoft Internet Information Services (IIS)
server to synchronize the subscription. This option is available only if the publication is enabled for Web
synchronization. For more information, see Web Synchronization for Merge Replication.
If you select True for Use Web Synchronization:
Enter the full address to the IIS server in Web server address.
Click the Web Server Connection row, and then click the properties button (...) to set or change the
account under which the Subscriber connects to the IIS server.
Change Web server timeout if necessary. The timeout is the length of time, in seconds, before a Web
synchronization request expires.
For more information about configuration, see Configure Web Synchronization.
See Also
Subscription Properties - Publisher
Warehouse
The Subscription Properties dialog box at the Publisher allows you to view and set properties for push
subscriptions. You can also view some properties for pull subscriptions, but the Subscriptions Properties dialog
box at the Subscriber displays additional properties and allows properties to be modified.
Each property in the Subscription Properties dialog box includes a description. Click a property to see its
description displayed at the bottom of the dialog box. This topic provides additional information on a number of
properties, most of which are displayed at the Publisher only for push subscriptions. The properties are grouped
into the following categories:
Properties that apply to all subscriptions.
Properties that apply to transactional subscriptions.
Properties that apply to merge subscriptions.
If an option is displayed as read-only, it can only be set when the subscription is created. If you want to set
options that are not available in the New Subscription Wizard, create the subscription with stored
procedures. For more information, see Create a Pull Subscription and Create a Push Subscription.
Options for all subscriptions

Security
Click the Agent process account row, and then click the properties button (...) to change the account under which
the Distribution Agent or Merge Agent runs at the Distributor. To change the account under which the Distribution
Agent or Merge Agent makes connections to the Subscriber, click Subscriber connection, and then click the
properties button (...).
For more information about the permissions required for each agent, see Replication Agent Security Model.
Options for transactional subscriptions

Prevent transaction looping
Determines whether the Distribution Agent sends transactions that originated at the Subscriber back to the
Subscriber. This option is used for bidirectional transactional replication. For more information, see Bidirectional
Transactional Replication.
Updatable subscription
Determines whether Subscriber changes are replicated back to the Publisher. Changes can be replicated using
queued updating or immediate updating. The option Subscriber update method determines which method to
use. For more information, see Updatable Subscriptions for Transactional Replication.
Options for merge subscriptions

Partition definition (HOST_NAME)
For a publication that uses parameterized filters, merge replication evaluates one of two system functions (or both
if the filter references both functions) during synchronization to determine the data that a Subscriber should
receive: SUSER_SNAME() or HOST_NAME(). By default, HOST_NAME() returns the name of the computer on
which the Merge Agent is running, but you can override this value in the New Subscription Wizard. For more
information on parameterized filters and overriding HOST_NAME(), see Parameterized Row Filters.
Subscription type and Priority
Displays whether the subscription is a client or server subscription (this cannot be changed after the subscription
has been created). Server subscriptions can republish data to other Subscribers and can be assigned a priority for
conflict resolution.
If you selected a subscription type of server in the New Subscription Wizard, the Subscriber is given a priority that
is used during conflict resolution.
Resolve conflicts interactively
Determines whether to use the Interactive Resolver user interface to resolve conflicts during merge
synchronization. This requires a value of Enable for Use Windows Synchronization Manager. For more
information, see Interactive Conflict Resolution.
See Also
Tools Reference (Replication)
Warehouse
Microsoft SQL Server provides several tools for implementing, administering, and troubleshooting replication.
These include SQL Server Management Studio, programming interfaces, and other Microsoft Windows
components.
See Also
Replication Monitor
Warehouse
This section of the documentation includes information on the Replication Monitor. The pages and dialog boxes
displayed in the monitor differ depending on the type of replication and the version of Microsoft SQL Server that is
monitored.
Replication Monitor, Main Page
Add Publisher
Distributor Settings
Distributor Information, Publications
Distributor Information, Subscription Watch List (Transactional Publication, SQL Server 2005 and Later)
Distributor Information, Subscription Watch List (Merge Publication, SQL Server 2005 and Later)
Distributor Information, Subscription Watch List (Snapshot Publication, SQL Server 2005 and Later)
Distributor Information, Agents
Publisher Settings
Publisher Information, Publications
Publisher Information, Subscription Watch List (Transactional Publication, SQL Server 2005 and Later)
Publisher Information, Subscription Watch List (Merge Publication, SQL Server 2005 and Later)
Publisher Information, Subscription Watch List (Snapshot Publication, SQL Server 2005 and Later)
Publisher Information, Agents
Publication Information, All Subscriptions (Transactional Publication)
Publication Information, All Subscriptions (Merge Publication)
Publication Information, All Subscriptions (Snapshot Publication)
Publication Information, Warnings (Transactional Publication, SQL Server 2005 and Later)
Publication Information, Warnings (Merge Publication, SQL Server 2005 and Later)
Publication Information, Warnings (Snapshot Publication, SQL Server 2005 and Later)
Publication Information, Agents (Transactional Publication)
Publication Information, Agents (Merge Publication)
Publication Information, Agents (Snapshot Publication)
Publication Information, Tracer Tokens (Transactional Publication, SQL Server 2005 and Later)
Subscription, Undistributed Commands (Transactional Subscription, SQL Server 2005 and Later)
Subscription, Publisher to Distributor History (Transactional Subscription)
Subscription, Distributor to Subscriber History (Transactional Subscription)
Subscription, Synchronization History (Merge Subscription, SQL Server 2005 and Later)
Subscription, Synchronization History (Merge Subscription, SQL Server 2000)
Subscription, Distributor to Subscriber History (Snapshot Subscription)
Log Reader Agent
Queue Reader Agent
Snapshot Agent
Filter Settings
Sort Columns
See Also
Start the Replication Monitor
Replication Monitor, Main Page
Warehouse
Replication Monitor allows you to track the status and performance of publications and subscriptions across a
replication topology. The following topics provide more information:
For an overview of Replication Monitor, see Monitoring Replication.
The left pane of Replication Monitor is focused on Publishers and groups of Publishers. Add one or more
Publishers to Replication Monitor to display publication and subscription information. For more information,
see Add and Remove Publishers from Replication Monitor.
For information about tasks that can be performed in Replication Monitor, see the following topics:
Refresh Data in Replication Monitor
View Information and Perform Tasks for a Publication (Replication Monitor)
View Information and Perform Tasks for the Agents Associated With a Publication (Replication
Monitor)
View Information and Perform Tasks for the Agents Associated With a Subscription (Replication
Monitor)
Measure Latency and Validate Connections for Transactional Replication
Set Thresholds and Warnings in Replication Monitor
Allow Non-Administrators to Use Replication Monitor
See Also
Add Publisher
Warehouse
The Add Publisher dialog box allows you to add to one or more Publishers to the left pane of Replication Monitor.
After adding a Publisher, selecting the Publisher in the left pane shows information on the Publisher in the right
pane.
Options
Add
Click to select a type of Publisher to add, which launches the Connect to Server dialog box. The options are:
Add SQL Server Publisher
Connect to the Publisher using the Connect to Server dialog box.
Add Oracle Publisher
Connect to the Microsoft SQL Server Distributor associated with the Oracle Publisher using the Connect to
Server dialog box.
Specify a Distributor and Add Its Publishers
Connect to the SQL Server Distributor associated with one or more Publishers using the Connect to Server
dialog box.
After successfully connecting to the Publisher or Distributor, the name of each Publisher and its Distributor
are displayed in the grid at the top of the dialog box.
NOTE
The Distributor and Publisher often run on the same instance of SQL Server, but the Distributor can run on another instance
(this configuration is referred to as a remote Distributor).
Remove
Select a Publisher in the grid at the top of the dialog box, and click Remove to remove the Publisher from the list of
Publishers to be added.
NOTE
This button cannot be used to remove a Publisher that is already displayed in Replication Monitor. To remove a Publisher
that is already displayed right-click the Publisher in the left pane of Replication Monitor and click Remove.
Connect automatically when Replication Monitor starts

Select to allow Replication Monitor to automatically connect to the Distributor and retrieve status information for
the Publisher selected in the grid at the top of the dialog box. If this checkbox is cleared, you must manually connect
after launching Replication Monitor: right-click the Publisher in the left pane of Replication Monitor, and click
Connect.
Automatically refresh the status of this Publisher and its publications
Select to allow Replication Monitor to automatically refresh status for the Publisher selected in the grid at the top of
the dialog box. If this option is selected, Replication Monitor polls the Distributor for status information on the
Publisher and its publications. The polling interval is set by the Refresh rate option. For more information on
refresh in Replication Monitor, see Caching, Refresh, and Replication Monitor Performance.
Refresh rate
Enter a value (in seconds) to specify how frequently Replication Monitor should poll the Distributor for status.
Lower values result in more frequent polling, which can affect performance at the Distributor if you are monitoring
a large number of Publishers. It is recommended that you test your system to determine an appropriate value. The
Refresh rate setting is also used if you select Auto Refresh in any of the detail windows in Replication Monitor.
Show this Publisher in the following group
Select a Publisher group from the list. The Publisher is displayed under this group in the left pane. Groups provide a
way to organize Publishers and have no effect on how replication functions. If no groups are defined or you want to
create a new one, click New Group.
New Group
Click to create a new Publisher group. A Publisher group provides a convenient way to organize Publishers within
Replication Monitor. Groups do not affect the replication of data or the relationship among servers in a replication
topology.
See Also
Distributor Settings
Warehouse
The Distributor Settings dialog box enables you to change settings for Distributors that were added to the left
pane in Replication Monitor.
Options
Select to let Replication Monitor connect to the Distributor and retrieve status information.
Connection
Click to display the Connect to Server dialog box. This enables you to view and change the connection properties
and credentials that Replication Monitor uses to connect to the Distributor.
Automatically refresh the status of this Distributor and its publications
Select to let Replication Monitor automatically refresh the status for the Distributor. If this option is selected,
Replication Monitor polls the Distributor for status information based on the polling interval set by the Refresh
rate option. For more information about refresh in Replication Monitor, see Caching, Refresh, and Replication
Monitor Performance.
Refresh rate
Lower values result in more frequent polling. This can affect performance at the Distributor if you are monitoring
many Publishers. We recommend that you test your system to determine an appropriate value. The Refresh rate
setting is also used if you select Auto Refresh in any of the detail windows in Replication Monitor.
Show all Publishers of this Distributor in the following group
way for you to organize Publishers and do not affect how replication functions.
New Group
Click to create a new Publisher group. A Publisher group provides a way for you to conveniently organize
Publishers within Replication Monitor. Groups do not affect the replication of data or the relationship among
servers in a replication topology.
See Also
Distributor Information, Publications
Warehouse
The Publications tab provides summary information for all publications at the Distributor that is selected in the
left pane.
Options
The information that is displayed about the publications supported by the Distributor includes a column that
contains the SQL Server instance of the Publisher. Otherwise, the publication information is the same as the
publication information that is provided when you view publications in the Publisher view of Replication Monitor.
For more information about the columns in the Publications tab, see Publisher Information, Publications.
See Also
Distributor Info, Subscription Watch List (Transaction
Pub, SQL 2005+)
Warehouse
Information for transactional subscriptions includes the name of the Publisher. Otherwise, the functionality and the
information that is provided in this dialog box is the same as in the Publisher view. For more information about
how to use this dialog box, see Publisher Information, Subscription Watch List (Transactional Publication, SQL
Server 2005 and Later).
See Also
Distributor Info, Subscription Watch List (Merge Pub,
SQL 2005+)
Warehouse
Information for merge publication subscriptions includes the name of the Publisher. Otherwise, the functionality
and the information that is provided in this dialog box is the same as in the Publisher view. For more information
about how to use this dialog box, see Publisher Information, Subscription Watch List (Merge Publication, SQL
See Also
Distributor Info, Subscription Watch List (Snapshot
Pub, SQL 2005+)
Warehouse
Information for snapshot publication subscriptions includes the name of the Publisher. Otherwise, the functionality
and the information that is provided in this dialog box is the same as in the Publisher view. For more information
about how to use this dialog box, see Publisher Information, Subscription Watch List (Snapshot Publication, SQL
See Also
Distributor Information, Agents
Warehouse
The Agents tab displays information about the agents and maintenance jobs that are associated with the Publisher
and Subscriber.
The agents that are available in the Agents tab for a Distributor in Distributor view include all the agents that are
available in the Agents tab for a Publisher. However, the Agents tab for a Distributor in Distributor view also
includes a Distributor Agent and a Merge Agent.
For more information about the Snapshot, Log Reader, and Queue Reader agents, and maintenance jobs, see
Publisher Information, Agents. Notice that when you are viewing agent information on the Agents tab for a
Distributor, Publisher information is present for the Snapshot and Log Reader agents. However, in the Agents tab
for a Distributor in Distributor view, you can also select Distributor Agent and Merge Agent.
Options
The following sections describe the data that is displayed on this tab for the Distributor Agent and Merge Agent.
Distributor Agent
Status
The status of the agent. The following list shows the possible status values:
Error
Retry
Running
Not Running
Never started
Publisher
The SQL Server instance of the Publisher.
Publication
The name of the publication with which the agent is associated.
Subscription
The name of the subscription, in the form: [SubscriberName].[Database].
Type
Type of replication: push, pull, or Anonymous.
Last Start Time
The last time at which the agent started.
Duration
The length of time that the agent has run. The time represents elapsed time if the agent is currently running,
and total time if the agent has run previously.
Last Action
The last action that was performed during the most recent run of the agent.
Delivery Rate
The rate, in commands per second, at which initialization commands are committed in the distribution
database during the most recent run of the agent.
Latency
The time, in seconds, that has elapsed between the most recent change being committed in the publication
database, and the corresponding command being committed in the distribution database.
#Trans
The number of transactions committed in the distribution database during the most recent run of the agent.
#Cmds
The number of commands committed in the distribution database during the most recent run of the agent. A
command is the same as a data change, such as an update.
Avg. #Cmds
The average number of commands per transaction during the most recent run of the agent.
Merge Agent
Status
Error
Retry
Running
Not Running
Never started
Publisher
The SQL Server instance of the Publisher.
Publication
Subscription
The name of the subscription, in the form: [SubscriberName].[Database].
Type
Type of replication: push, pull, or Anonymous.
Last Start Time
Duration
The length of time that the agent has run. The time represents elapsed time if the agent is currently running,
and total time if the agent has run previously.
Last Action
The last action that was performed during the most recent run of the agent.
Delivery Rate
The rate, in commands per second, at which changes are committed in the distribution database.
Publisher Inserts
Number of INSERT commands applied at the Publisher.
Publisher Updates
Number of UPDATE commands applied at the Publisher.
Publisher Deletes
Number of DELETE commands applied at the Publisher.
Publisher Conflicts
The number of conflicts occurring at the Publisher during the merge process.
Subscriber Inserts
Number of INSERT commands applied at the Subscriber.
Subscriber Updates
Number of UPDATE commands applied at the Subscriber.
Subscriber Deletes
Number of DELETE commands applied at the Subscriber.
Subscriber Conflicts
The number of conflicts occurring at the Subscriber during the merge process.
See Also
View Information and Perform Tasks for the Agents Associated With a Publication (Replication Monitor)
Publisher Settings
Warehouse
The Publisher Settings dialog box allows you to change settings for Publishers that have been added to the left
pane in Replication Monitor.
Options
Publisher Connection
Click to launch the Connect to Server dialog box, which allows you to view and change the connection properties
and credentials Replication Monitor uses to connect to a Publisher.
Distributor Connection
Displayed only if the Publisher uses a remote Distributor. Click to launch the Connect to Server dialog box, which
allows you to view and change the connection properties and credentials Replication Monitor uses to connect to
the remote Distributor.
Select to allow Replication Monitor to automatically connect to the Distributor and retrieve status information for
the Publisher selected in the grid at the top of the dialog box. If this checkbox is cleared, you must manually connect
after launching Replication Monitor: right-click the Publisher in the left pane of Replication Monitor, and click
Connect.
Automatically refresh the status of this Publisher and its publications
Select to allow Replication Monitor to automatically refresh status for the Publisher selected in the grid at the top of
the dialog box. If this option is selected, Replication Monitor polls the Distributor for status information on the
Publisher and its publications. The polling interval is set by the Refresh rate option. For more information on
refresh in Replication Monitor, see Caching, Refresh, and Replication Monitor Performance.
Refresh rate
Lower values result in more frequent polling, which can affect performance at the Distributor if you are monitoring
a large number of Publishers. It is recommended that you test your system to determine an appropriate value. The
Refresh rate setting is also used if you select Auto Refresh in any of the detail windows in Replication Monitor.
Show this Publisher in the following group
way to organize Publishers and have no effect on how replication functions.
New Group
Click to create a new Publisher group. A Publisher group provides a convenient way to organize Publishers within
Replication Monitor. Groups do not affect the replication of data or the relationship among servers in a replication
topology.
See Also
Publisher Information, Publications
Warehouse
The Publications tab provides summary information for all publications at the Publisher selected in the left pane.
Options
To change the way that the grid displays data, right-click the grid, and then click one of the following options:
Sort: Sort on one or more columns in the Sort Columns dialog box.
Choose Columns to Show: Select which columns to display and the order in which to display them in the
Choose Columns dialog box.
Filter: Filter rows in the grid based on column values in the Filter Settings dialog box.
Clear Filter: Clear any filter settings for the grid.
Filter settings are specific to each grid. Column selection and sorting are applied to all grids of the same
type, such as the publications grid for each Publisher.
Status
The status of each publication, which is determined by the highest priority status of its subscriptions. By
default, the grid containing publication information is sorted by the Status column. The following list shows
the possible status values and the sort order for the values (for example, errors are always shown at the top
of the grid):
Error
Performance critical
Retrying failed command
OK
The status value Performance critical is relevant for transactional subscriptions and merge subscriptions;
for transactional subscriptions, it can be displayed only if a threshold is set. For information on performance
measurements and setting thresholds, see Monitor Performance with Replication Monitor and Set
Thresholds and Warnings in Replication Monitor.
Publication
The name of each publication, in the form PublicationDatabaseName: PublicationName.
Subscriptions
The number of subscriptions for each publication.
Synchronizing
The number of subscriptions for each publication that are currently synchronizing:
For transactional replication, "synchronizing" means that the Distribution Agent is running, but data is not
necessarily being replicated.
For merge replication, "synchronizing" means that the Merge Agent is running and that data is currently
being replicated.
For snapshot replication, "synchronizing" means that the Distribution Agent is running and that data is
currently being replicated.
Current Average Performance and Current Worst Performance
Microsoft SQL Server 2005 and later versions only. The average performance rating and the worst
performance rating, respectively, for all subscriptions to a publication. Ratings are based on the most recent
measurements taken by Replication Monitor and do not reflect the performance of a subscription over time.
For transactional replication, Replication Monitor displays a value only for publications that have
performance thresholds defined. If performance thresholds are not defined for a publication, this column
displays Not enabled. For merge replication, Replication Monitor displays a value after five
synchronizations have occurred with 50 or more changes each over the same type of connection (dial-up or
LAN). If there have been less than five synchronizations with 50 or more changes or the most recent
synchronization has less than 50 changes, this column is blank.
The performance rating is one of the following values:
Excellent
Good
Fair
Poor
Critical
For more information about how performance ratings are defined and how performance thresholds are set,
see Monitor Performance with Replication Monitor.
See Also
Publisher Information, Subscription Watch List
(Transactional)
Warehouse
The Subscription Watch List tab is available for Distributors running SQL Server 2005 and later versions; it is
intended to display information on subscriptions from all publications available at the selected Publisher. You can
filter the list of subscriptions to see errors, warnings, and any poorly performing subscriptions. This tab provides a
single location for an administrator to monitor all replication activity at a Publisher: Replication Monitor displays all
subscriptions that require attention, based on the selected replication type and on the option chosen in the Show
drop-down list box. Because the items displayed on this tab are based on current status and performance,
subscriptions are displayed on this page only if they match the option in the Show list box at the current time.
Options
For more detailed information and tasks related to a subscription, right-click the row for that subscription, and then
click an option on the shortcut menu. To change the way that the grid displays data, right-click the grid, and then
click one of the following options:
Show Transactional Subscriptions
Select the type of subscriptions (transactional, snapshot, or merge) to display for the selected Publisher.
Show
Select the subscription states to display for the selected subscription type. For example, you can select to
display only those subscriptions that have an error.
Status
The status of each subscription, which is determined by the status of the Distribution Agent or the Log
Reader Agent (the higher priority status is displayed; the status can also be determined by the Queue Reader
Agent if queued updating subscriptions are used).
By default, the grid containing subscription information is sorted by the Status column (and then sorted by
the Performance column for those subscriptions with the same status). The following list shows the
possible status values and the sort order for the values (for example, errors are always shown at the top of
the grid).
Error
Expiring soon/Expired
Uninitialized subscription
Not Running
Running
The sort order also determines which value is displayed if a given subscription is in more than one state. For
example, if a subscription has an error and is expiring soon, the Status column displays Error.
The status values Performance critical, Expiring soon/Expired, and Uninitialized subscription are
warnings. When a warning is displayed, the Status column also displays if an agent is running. For example,
the status could be Running, Performance critical.
The status values Performance critical and Expiring soon/Expired are displayed only if thresholds are
set. For information about performance measurements and setting thresholds, see Monitor Performance
with Replication Monitor and Set Thresholds and Warnings in Replication Monitor.
Subscription
The name of each subscription, in the form: SubscriberName: SubscriptionDatabaseName.
Publication
The name of the publication with which a subscription synchronizes, in the form: PublicationDatabaseName:
PublicationName.
Performance
The performance rating for each subscription is based on the most recent measurements taken by
Replication Monitor and does not reflect historical performance. Performance is measured for subscriptions
to publications that have performance thresholds defined; if performance thresholds are not defined for a
publication, this column displays Not enabled. The performance rating is one of the following values:
Excellent
Good
Fair
Poor
Critical
If performance is critical, Performance Critical is displayed in the Status column. For more information
about how performance ratings are defined and how performance thresholds are set, see Monitor
Performance with Replication Monitor.
Latency
The average amount of time that elapses between a transaction being committed at the Publisher and the
corresponding transaction being committed at the Subscriber. The latency displayed is based on the most
recent measurements taken by Replication Monitor. For more information about measuring latency, see
Measure Latency and Validate Connections for Transactional Replication.
Last Synchronization
The time when the Distribution Agent last ran. If synchronization is in progress, In progress is displayed.
See Also
(Merge Publication)
Warehouse
Options
Show Merge Subscriptions
Show
Status
The status of each subscription, which is determined by the status of the Merge Agent.
the grid).
Error
Long-running merge
Synchronizing
Not synchronizing
The status values Performance critical, Long-running merge, Expiring soon/Expired, and
Uninitialized subscription are warnings. When a warning is displayed, the Status column also displays if
an agent is synchronizing. For example, the status could be Synchronizing, Performance critical.
The status values Expiring soon/Expired and Long-running merge can be displayed only if thresholds
are set. The status value Performance critical can be displayed only after five synchronizations of
subscriptions with the same connection type (dial-up or LAN). For information on performance
Subscription
The name of each subscription, in the form:SubscriberName: SubscriptionDatabaseName.
Friendly Name
The description of each subscription. The description is entered in the Subscription Properties dialog box
or specified with the @description parameter of sp_addmergesubscription or
sp_addmergepullsubscription. Users often use the description as a "friendly name" or nickname for the
subscription.
Publication
PublicationName.
Performance
The performance rating for each subscription, based on the most recent measurements of delivery rate
taken by Replication Monitor. The rating is determined by comparing individual subscription performance to
the average historical performance of subscriptions to the publication that have the same connection type
(dial-up or LAN). Replication Monitor displays a value after five synchronizations have occurred with 50 or
more changes each over the same type of connection. If there have been less than five synchronizations with
50 or more changes or the most recent synchronization has less than 50 changes, this column is blank.
NOTE
Performance is based on the connection type displayed in the Connection column; therefore it is possible for a subscription
with a lower delivery rate to display a better performance rating than another subscription if the first subscription is
synchronized over a slower connection.

Excellent
Good
Fair
Poor
For more information about how performance ratings are defined and how performance thresholds are set,
Delivery Rate
The number of rows per second processed by the Merge Agent.
The time at which the Merge Agent last ran. Changes may or may not have been processed during this
synchronization. If synchronization is in progress, a percentage complete value is displayed.
Duration
The amount of time the Merge Agent has run during the last synchronization. The time represents elapsed
time if the Merge Agent is currently synchronizing and total time if the Merge Agent has synchronized
previously.
Connection
The type of connection between the Subscriber and the Publisher. The possible values are LAN, Dialup, and
Internet. The Internet value is displayed if the subscription uses Web synchronization.
See Also
(Snapshot)
Warehouse
Options
Show Snapshot Subscriptions
Show
Status
The status of each subscription, which is determined by the status of the Snapshot Agent or the Distribution
Agent (the higher priority status is displayed).
By default, the grid containing subscription information is sorted by the Status column. The following list
shows the possible status values and the sort order for the values (for example, errors are always shown at
the top of the grid).
Error
Synchronizing
Not synchronizing
The status values Expiring soon/Expired and Uninitialized subscription are warnings. When a warning
is displayed, the Status column also displays if an agent is running. For example, the status could be
Running, Expiring soon/Expired.
The status value Expiring soon/Expired is displayed only if a threshold is set. For information on setting
thresholds, see Set Thresholds and Warnings in Replication Monitor.
Subscription
Publication
PublicationName.
The time at which the Distribution Agent last ran. If synchronization is in progress, In progress is displayed.
See Also
Publisher Information, Agents
Warehouse
The Agents tab displays information about the agents and maintenance jobs that are associated with the Publisher:
Snapshot Agent, which is displayed for all publications.
Log Reader Agent, which is displayed for all transactional publications.
Queue Reader Agent, which is displayed for those transactional publications that are enabled for queued
Maintenance jobs, displayed for all publications:
Reinitialize subscriptions that have data validation failures
Agent history cleanup: distribution
Replication monitoring refresher for distribution
Replication agents checkup
Distribution cleanup: distribution
Expired subscription cleanup
For more information about these jobs, see Replication Agent Administration.
Options
To display information about an agent or job, select from the Agent and Job Types drop-down menu. For more
detailed information and tasks that are related to an agent or job, right-click the row for that agent or job, and then
The following sections describe the data that is displayed on this tab for each agent or job.
Snapshot Agent
Status
Error
Retry
Running
Completed
Publication
Last Start Time
Duration
The length of time the agent has run. The time represents elapsed time if the agent is currently running, and
total time if the agent has run previously.
Last Action
The last action performed during the most recent run of the agent.
Delivery Rate
The rate, in commands per second, at which initialization commands are committed in the distribution
database during the most recent run of the agent.
#Trans
#Cmds
The number of commands committed in the distribution database during the most recent run of the agent.
A command is equivalent to a data change, such as an update.
Log Reader Agent
Status
Error
Retry
Running
Not running
Publication Database
Last Start Time
Duration
The length of time the agent has run. The time represents elapsed time if the agent is currently running, and
Last Action
Delivery Rate
Latency
The amount of time, in seconds, that has elapsed between the most recent change being committed in the
publication database, and the corresponding command being committed in the distribution database.
#Trans
#Cmds
The number of commands committed in the distribution database during the most recent run of the agent.
A command is equivalent to a data change, such as an update.
Avg. #Cmds
Queue Reader Agent
Status
Error
Retry
Running
Not running
Distribution Database
The name of the distribution database with which the agent is associated.
Last Start Time
Duration
The length of time the agent has run. The time represents elapsed time if the agent is currently running and
Last Action
Delivery Rate
Latency
The amount of time, in seconds, that has elapsed between the most recent change being committed in a
subscription database, and the corresponding command being committed in the publication database.
#Trans
The number of transactions committed in the publication database during the most recent run of the agent.
#Cmds
The number of commands committed in the publication database during the most recent run of the agent. A
command is equivalent to a data change, such as an update.
Avg. #Cmds
Maintenance Jobs
Status
The status of each job. The following list shows the possible status values:
Error
Retry
Running
Not running
Job
The name of the job.
Last Start Time
The last time at which the job started.
Duration
The length of time the job has run. The time represents elapsed time if the job is currently running, and total
time if the job has run previously.
Last Action
The last action performed during the most recent run of the job.
See Also
Publication Information, All Subscriptions
(Transactional Publication)
Warehouse
The All Subscriptions tab displays information on all subscriptions to the selected transactional publication.
Options
Filter settings are specific to each grid. Column selection and sorting are applied to all grids of the same type,
such as the publications grid for each Publisher.
Show
Microsoft SQL Server 2005 and later versions only. Select the subscription states to display for the selected
subscription type. For example, you can select to display only those subscriptions that have an error.
Status
The status of each subscription, which is determined by the status of the Distribution Agent or the Log
Reader Agent (the higher priority status is displayed; the status can also be determined by the Queue Reader
Agent if queued updating subscriptions are used).
the grid).
Error
Performance critical ( SQL Server 2005 and later versions only)
Expiring soon/Expired ( SQL Server 2005 and later versions only)
Uninitialized subscription ( SQL Server 2005 and later versions only)
Not Running
Running
The status values Performance critical, Expiring soon/Expired, and Uninitialized subscription are
warnings. When a warning is displayed, the Status column also displays if an agent is running. For example,
the status could be Running, Performance critical.
The status values Performance critical and Expiring soon/Expired are displayed only if thresholds are
set. For information on performance measurements and setting thresholds, see Monitor Performance with
Replication Monitor and Set Thresholds and Warnings in Replication Monitor.
Subscription
Performance
SQL Server 2005 and later versions only. The performance rating for each subscription is based on the most
recent measurements taken by Replication Monitor and does not reflect historical performance.
Performance is measured for subscriptions to publications that have performance thresholds defined; if
performance thresholds are not defined for a publication, this column displays Not enabled. The
performance rating is one of the following values:
Excellent
Good
Fair
Poor
Critical
If performance is critical, Performance Critical is displayed in the Status column. For more information on
how performance ratings are defined and how performance thresholds are set, see Monitor Performance
with Replication Monitor.
Latency
SQL Server 2005 and later versions only. The average amount of time that elapses between a transaction
being committed at the Publisher and the corresponding transaction being committed at the Subscriber. The
latency displayed is based on the most recent measurements taken by Replication Monitor. For more
information about measuring latency, see Measure Latency and Validate Connections for Transactional
Replication.
See Also
View Information and Perform Tasks for the Agents Associated With a Subscription (Replication Monitor)
Publication Information, All Subscriptions (Merge
Publication)
Warehouse
The All Subscriptions tab displays information on all subscriptions to the selected merge publication.
Options
Show
Status
The status of each subscription, which is determined by the status of the Merge Agent.
the grid).
Error
Performance critical ( SQL Server 2005 and later versions only)
Long-running merge ( SQL Server 2005 and later versions only)
Synchronizing
Not synchronizing
The status values Performance critical, Long-running merge, Expiring soon/Expired, and
Uninitialized subscription are warnings. When a warning is displayed, the Status column also displays if
an agent is synchronizing. For example, the status could be Synchronizing, Performance critical.
The status values Expiring soon/Expired and Long-running merge can be displayed only if thresholds
are set. The status value Performance critical can be displayed only after five synchronizations of
subscriptions with the same connection type (dial-up or LAN). For information about performance
Subscription
The name of each subscription, in the form:SubscriberName: SubscriptionDatabaseName.
Friendly Name
SQL Server 2005 and later versions only. The description of each subscription. The description is entered in
the Subscription Properties dialog box or specified with the @description parameter of
sp_addmergesubscription or sp_addmergepullsubscription. Users often use the description as a "friendly
name" or nickname for the subscription.
Performance
SQL Server 2005 and later versions only. The performance rating for each subscription, based on the most
recent measurements of delivery rate taken by Replication Monitor. The rating is determined by comparing
individual subscription performance to the average historical performance of subscriptions to the
publication that have the same connection type (dial-up or LAN). Replication Monitor displays a value after
five synchronizations have occurred with 50 or more changes each over the same type of connection. If
there have been less than five synchronizations with 50 or more changes or the most recent synchronization
has less than 50 changes, this column is blank.
NOTE
Performance is based on the connection type displayed in the Connection column; therefore it is possible for a subscription
with a lower delivery rate to display a better performance rating than another subscription if the first subscription is
synchronized over a slower connection.

Excellent
Good
Fair
Poor
For more information on how performance ratings are defined and how performance thresholds are set, see
Monitor Performance with Replication Monitor.
Delivery Rate
The number of rows per second processed by the Merge Agent.
The time at which the Merge Agent last ran. Changes may or may not have been processed during this
synchronization. If synchronization is in progress, a percentage complete value is displayed.
Duration
The amount of time the Merge Agent has run during the last synchronization. The time represents elapsed
time if the Merge Agent is currently synchronizing and total time if the Merge Agent has synchronized
previously.
Connection
SQL Server 2005 and later versions only. The type of connection between the Subscriber and the Publisher.
The possible values are LAN, Dialup, and Internet. The Internet value is displayed if the subscription uses
Web synchronization.
See Also
Publication Information, All Subscriptions (Snapshot
Publication)
Warehouse
The All Subscriptions tab displays information on all subscriptions to the selected snapshot publication.
Options
Show
Status
The status of each subscription, which is determined by the status of the Snapshot Agent or the Distribution
Agent (the higher priority status is displayed).
By default, the grid containing subscription information is sorted by the Status column. The following list
shows the possible status values and the sort order for the values (for example, errors are always shown at
the top of the grid).
Error
Synchronizing
Not synchronizing
The status values Expiring soon/Expired and Uninitialized subscription are warnings. When a warning
is displayed, the Status column also displays if an agent is running. For example, the status could be
Running, Expiring soon/Expired.
The status value Expiring soon/Expired is displayed only if a threshold is set. For information on setting
thresholds, see Set Thresholds and Warnings in Replication Monitor.
Subscription
The time at which the Distribution Agent last ran. If synchronization is in progress, In progress is displayed.
See Also
Publication Information, Warnings (Transactional
Publication)
Warehouse
The Warnings tab is available for Distributors that are running SQL Server 2005 and later versions. The Warnings
tab allows you to perform the following tasks for the selected publication:
Enable warnings to be displayed in Replication Monitor.
Specify thresholds associated with warnings.
Define alerts associated with warnings.
Warnings, Thresholds, and Alerts

By default, Replication Monitor displays warnings for uninitialized subscriptions: a status of Uninitialized
subscription is displayed as a warning in the Status column of pages that include subscription information. For
transactional publications, you can specify whether these additional conditions result in warnings:
Imminent subscription expiration.
This corresponds to the option Warn if a subscription will expire within the threshold. If the specified
threshold is met or exceeded, the subscription status is displayed as Expiring soon/Expired (unless an
issue with a higher priority needs to be displayed).
Exceeding the specified latency. This is the amount of time that elapses between a transaction being
committed at the Publisher and the corresponding transaction being committed at the Subscriber.
This corresponds to the option Warn if latency exceeds the threshold. If the specified threshold is met or
exceeded, the subscription status is displayed as Performance critical (unless an issue with a higher
priority needs to be displayed). The threshold is also used to provide a performance rating, which is
displayed in the Performance column of pages that include subscription information. The performance
rating is one of the following values:
Excellent
Good
Fair
Poor
Critical
When you enable a warning, you also set a threshold. For example, if you enable the warning Warn if
latency exceeds the threshold, select the amount of time allowable between a transaction being
committed at the Publisher and the transaction being committed at the Subscriber.
In addition to displaying a warning in Replication Monitor, reaching a threshold can also trigger an alert.
Alerts are defined by clicking Configure Alerts and providing information in the Configure Replication
Alerts dialog box.
Options
Enabled
Select to enable a warning and specify a threshold.
Warning
A description of the warning associated with a threshold.
Threshold
Specify a value for the threshold.
Configure Alerts
Select a row in the Warnings grid, and click Configure Alerts to launch the Configure Replication Alerts dialog
box. The dialog box allows you to define an alert, which is associated with the selected threshold and warning.
Discard Changes
Click to discard any changes to warnings and thresholds.
NOTE
Clicking Discard Changes does not affect alerts defined in the Configure Replication Alerts dialog box.
Save Changes
Click to save any changes to warnings and thresholds.
See Also
Monitor Performance with Replication Monitor
Publication Information, Warnings (Merge
Publication, SQL Server 2005 and Later)
Warehouse
Enable warnings.

merge publications, you can specify whether these additional conditions result in warnings:
Imminent subscription expiration.
This corresponds to the option Warn if a subscription will expire within the threshold. If the specified
threshold is met or exceeded, the subscription status is displayed as Expiring soon/Expired (unless an
issue with a higher priority needs to be displayed).
Exceeding the specified synchronization time.
This corresponds to the options Warn if a merge length for dialup connections exceeds the threshold
and Warn if a merge length for LAN connections exceeds the threshold. Both of these thresholds can
be set, but only one is used during a given synchronization. The Merge Agent applies the appropriate
threshold based on the connection type.
If the specified threshold is met or exceeded, the subscription status is displayed as Long-running merge
(unless an issue with a higher priority needs to be displayed).
Falling short of processing the specified number of rows in a given amount of time.
This corresponds to the options Warn if rows merged per second for dialup connections is less than
the threshold and Warn if a merge length for LAN connections exceeds the threshold. Both of these
thresholds can be set, but only one is used during a given synchronization. The Merge Agent applies the
appropriate threshold based on the connection type.
If the specified threshold is met or exceeded, the subscription status is displayed as Performance critical
(unless an issue with a higher priority needs to be displayed).
When you enable a warning, you also set a threshold. For example, if you enable the warning Warn if a
merge length for LAN connections exceeds the threshold, set the maximum allowable length of time
for a merge synchronization.
In addition to displaying a warning in Replication Monitor, reaching a threshold can also trigger an alert.
Alerts are defined by clicking Configure Alerts and providing information in the Configure Replication
Alerts dialog box.
Options
Enabled
Alert
Select to enable the alert setting for a given replication warning.
Warning
Threshold
Configure Alerts
Discard Changes
NOTE
Save Changes
See Also
Publication Information, Warnings (Snapshot
Publication, SQL Server 2005 and Later)
Warehouse
Enable warnings.

snapshot publications, you can also specify that imminent subscription expiration results in a warning by setting
the option Warn if a subscription will expire within the threshold. If the specified threshold is met or
exceeded, the subscription status is displayed as Expiring soon/Expired (unless an issue with a higher priority
needs to be displayed).
In addition to displaying a warning in Replication Monitor, reaching a threshold can also trigger an alert. Alerts are
defined by clicking Configure Alerts and providing information in the Configure Replication Alerts dialog box.
Options
Enabled
Warning
Threshold
Configure Alerts
Discard Changes
NOTE
Save Changes
See Also
Publication Information, Agents (Transactional
Publication)
Warehouse
The Agents tab displays summary information on the agents for the selected publication. Information on the
Snapshot Agent and Log Reader Agent is displayed for all transactional publications. Information on the Queue
Reader Agent is displayed for those transactional publications that are enabled for queued updating subscriptions.
Options
For more detailed information and tasks related to an agent, right-click the row for that agent, and then click an
option on the shortcut menu. To change the way that the grid displays data, right-click the grid, and then click one
of the following options:
Status
The status of each replication agent associated with the publication. The following list shows the possible
status values:
Error
Retrying failed commands
Not running
Running
Completed
Agent
The name of each replication agent associated with the publication. The Distribution Agent is associated with
subscriptions to this publication. For more information, see View Information and Perform Tasks for the
Agents Associated With a Subscription (Replication Monitor).
Last Start Time
The last time the agent started.
Duration
The amount of time the agent has run. The time represents elapsed time if the agent is currently running and
Last Action
See Also
Publication Information, Agents (Merge Publication)
Warehouse
The Agents tab displays summary information on the Snapshot Agent for the selected publication.
Options
For more detailed information and tasks related to the Snapshot Agent, right-click the row for the agent, and then
Status
The status of the Snapshot Agent. The following list shows the possible status values:
Error
Not running
Completed
Agent
The Snapshot Agent. This is the only agent associated with a merge publication. The Merge Agent is
associated with subscriptions to this publication. For more information, see View Information and Perform
Tasks for the Agents Associated With a Subscription (Replication Monitor).
Last Start Time
Duration
Last Action
See Also
Publication Information, Agents (Snapshot
Publication)
Warehouse
The Agents tab displays summary information on the Snapshot Agent for the selected publication.
Options
For more detailed information and tasks related to the Snapshot Agent, right-click the row for the agent, and then
Status
Error
Not running
Completed
Agent
The Snapshot Agent. This is the only agent associated with a snapshot publication. The Distribution Agent is
associated with subscriptions to this publication. For more information, see View Information and Perform
Tasks for the Agents Associated With a Subscription (Replication Monitor).
Last Start Time
Duration
Last Action
See Also
Publication Information, Tracer Tokens (SQL Server
2005 and Later)
Warehouse
The Tracer Tokens tab allows you to validate connections and to measure the latency of a system that uses
transactional replication. A token (a small amount of data) is written to the transaction log of the publication
database, marked as though it were a typical replicated transaction, and sent through the system, allowing a
calculation of:
How much time elapses between a transaction being committed at the Publisher and the corresponding
command being inserted in the distribution database at the Distributor.
How much time elapses between a command being inserted in the distribution database and the
corresponding transaction being committed at a Subscriber.
From these calculations, you can answer a number of questions, including:
Which Subscribers take the longest to receive a change from the Publisher?
Of the Subscribers expected to receive the tracer token, which, if any, have not received it?
Options
To change the way that the grid displays data, right-click the grid, and then click one of the following options:
Insert Tracer
Click to insert a tracer token in the transaction log at the Publisher.
Time inserted
Select a time at which a tracer token was inserted to display latency information from that time. By default,
information from the most recent time is displayed.
NOTE
Tracer token information is retained for the same time period as other historical data, which is governed by the history
retention period of the distribution database. For information about changing distribution database properties, see View and
Modify Distributor and Publisher Properties.
Subscription
The name of each subscription to the publication.
Publisher to Distributor
The elapsed time between a transaction being committed at the Publisher and the corresponding command being
inserted in the distribution database at the Distributor. A value of Pending indicates that the token has not yet
reached the Distributor. If the pending state persists, ensure that the Log Reader Agent is running.
Distributor to Subscriber
The elapsed time between a command being inserted in the distribution database and the corresponding
transaction being committed at a Subscriber. A value of Pending indicates that the token has not yet reached the
Subscriber. If the pending state persists, ensure that the Distribution Agent is running.
Total Latency
The elapsed time between a transaction being committed at the Publisher and the corresponding transaction being
committed at the Subscriber. This represents the end-to-end latency of the replication system for this Subscriber at
this time. A value of Pending indicates that the token has not yet reached the Subscriber.
See Also
Start and Stop a Replication Agent (SQL Server Management Studio)
Subscription, Undistributed Commands (Transactional
Subscription)
Warehouse
The Undistributed Commands tab displays information about the number of commands in the distribution
database that have not been delivered to the selected Subscriber, and the estimated time to deliver those
commands. For information about viewing the commands in the distribution database, see sp_replshowcmds
(Transact-SQL).
Options
Number of commands in the distribution database waiting to be applied to this Subscriber
The number of commands in the distribution database that have not been delivered to the selected Subscriber. A
command consists of one Transact-SQL data manipulation language (DML) statement or one data definition
language (DDL) statement.
Estimated time to apply these commands, based on past performance
The estimated amount of time to deliver commands to the Subscriber. If this value is greater than the amount of
time required to generate and apply a snapshot to the Subscriber, consider reinitializing the Subscriber. For more
information, see Reinitialize Subscriptions.
See Also
Subscription, Publisher to Distributor History
(Transactional Subscription)
Warehouse
The Publisher to Distributor History tab displays detailed information on the Log Reader Agent, including status,
history, informational messages, and any error messages.
Options
Select which Log Reader Agent sessions to view from the View menu, and then select a specific session in the grid
labeled Sessions of the Log Reader Agent. Detailed information on this session is displayed in the grid labeled
Actions in the selected session. If the selected session ended in an error, the text area labeled Error details or
message of the selected session is also displayed.
View
Select which Log Reader Agent sessions to view. The Log Reader Agent typically runs continuously, therefore there
might be only one session to view.
Status
The status of the Log Reader Agent. The following list shows the possible status values:
Error
Completed
Retrying
Running
Start Time
The start time of the session.
End Time
The end time of the session. If the agent has not stopped, this field is empty.
Duration
The amount of time the Log Reader Agent has run in this session. The time represents elapsed time if the
agent is currently running and the total time of the session if the agent session has ended.
Error Message
If a session ended in an error, this field displays the last error message logged by the Log Reader Agent. If a
session did not end in an error, this field is blank.
Action Message
All informational messages and error messages that the Log Reader Agent has logged during the selected
session.
Action Time
The time at which the action described in the Action Message column was performed.
Error details or message of the selected session
Displayed only if the selected session displays a value of Error in the Status column. This text area displays
detailed error information and the command that was attempted at the time of the error. It also includes
links to additional content related to the error.
See Also
Subscription, Distributor to Subscriber History
(Transactional Subscription)
Warehouse
The Distributor to Subscriber History tab displays detailed information on the Distribution Agent, including
status, history, informational messages, and any error messages.
Options
Select which Distribution Agent sessions to view from the View menu, and then select a specific session in the grid
labeled Sessions of the Distribution Agent. Detailed information on this session is displayed in the grid labeled
View
Select which Distribution Agent sessions to view. The Distribution Agent typically runs continuously, therefore there
Status
The status of the Distribution Agent. The following list shows the possible status values:
Error
Completed
Retrying
Running
Start Time
End Time
Duration
The amount of time the Distribution Agent has run in this session. The time represents elapsed time if the
Error Message
If a session ended in an error, this field displays the last error message logged by the Distribution Agent. If a
Action Message
All informational messages and error messages that the Distribution Agent has logged during the selected
session.
Action Time
See Also
Subscription, Synchronization History
Warehouse
The Synchronization History tab displays detailed information on the Merge Agent, including status, article
statistics, history, informational messages, and any error messages.
Options
Select which Merge Agent sessions to view from the View menu, and then select a specific session in the grid
labeled Sessions of the Merge Agent. Detailed information on this session is displayed in the grid labeled
Articles processed in the selected session.
View
Select which Merge Agent sessions to view.
Status
The status of the Merge Agent at the end of the session. The following list shows the possible status values:
Error
Completed
Retrying
Running
Start Time
End Time
Duration
The amount of time the Merge Agent has run in a session. The time represents elapsed time if the agent is
currently running and total time if the agent has run previously.
Uploaded Commands
The number of rows uploaded during the Merge Agent session.
Downloaded Commands
The number of rows downloaded during the Merge Agent session.
Error Message
If a session ended in an error, this field displays the last error message logged by the Merge Agent. If a
Article
The name of each article in the publication, and the following processing phases for the entire publication:
Initialization. This refers to starting the Merge Agent; this is not synonymous with initializing a
subscription, which involves applying a snapshot.
Schema changes and bulk inserts.
Upload changes to Publisher.
Download changes to Subscriber.
The phases are included so that the grid can display the amount of time and percentage of total time that
each phase accounts for in the selected session.
% of total
The percentage of total processing time that each phase accounts for in the selected session.
Duration
The amount of time spent in each processing phase. The time represents elapsed time if the Merge Agent is
currently running for the session and total time if the Merge Agent has run previously.
Inserts
The number of rows inserted in this phase of the selected session.
Updates
The number of rows updated in this phase of the selected session.
Deletes
The number of rows deleted in this phase of the selected session.
Conflicts
The number of conflicts in the selected session.
Schema Changes
The number of schema changes in the selected session. Schema changes can result from: schema changes
being replicated from the publication database; adding or dropping articles; and changes to article or
publication properties.
Last message of the selected session
This text area displays the last message in the selected session. If an error has occurred, it displays detailed
error information and the command that was attempted at the time of the error. It also includes links to
additional content related to the error.
See Also
Subscription, Synchronization History (Merge
Subscription, SQL Server 2000)
Warehouse
The Synchronization History tab displays detailed information on the Merge Agent, including status, history,
informational messages, and any error messages.
Options
Select which Merge Agent sessions to view from the View menu, and then select a specific session in the grid
labeled Sessions of the Merge Agent. Detailed information on this session is displayed in the grid labeled
View
Select which Merge Agent sessions to view. The Merge Agent typically runs continuously, therefore there might be
only one session to view.
Status
The status of the Merge Agent. The following list shows the possible status values:
Error
Completed
Retrying
Running
Start Time
End Time
Duration
The amount of time the Merge Agent has run in this session. The time represents elapsed time if the agent is
currently running and the total time of the session if the agent session had ended.
Error Message
If a session ended in an error, this field displays the last error message logged by the Merge Agent. If a
Action Message
All informational messages and error messages that the Merge Agent has logged during the selected
session.
Action Time
See Also
Subscription, Distributor to Subscriber History
(Snapshot Subscription)
Warehouse
The Distributor to Subscriber History tab displays detailed information on the Distribution Agent, including
status, history, informational messages, and any error messages.
Options
Select which Distribution Agent sessions to view from the View menu, and then select a specific session in the grid
labeled Sessions of the Distribution Agent. Detailed information on this session is displayed in the grid labeled
View
Select which Distribution Agent sessions to view.
Status
The status of the Distribution Agent. The following list shows the possible status values:
Error
Completed
Retrying
Running
Start Time
End Time
Duration
The amount of time the Distribution Agent has run in this session. The time represents elapsed time if the
agent is currently running and the total time of the session if the agent session had ended.
Error Message
If a session ended in an error, this field displays the last error message logged by the Distribution Agent. If a
Action Message
All informational messages and error messages that the Distribution Agent has logged during the selected
session.
Action Time
See Also
Log Reader Agent
Warehouse
The Log Reader Agent dialog box displays detailed information on the Log Reader Agent, including status, history,
Options
Select which Log Reader Agent sessions to view from the View menu, and then select a specific session in the grid
labeled Sessions of the Log Reader Agent. Detailed information on this session is displayed in the grid labeled
View
Select which Log Reader Agent sessions to view. The Log Reader Agent typically runs continuously, therefore there
Status
The status of the Log Reader Agent. The following list shows the possible status values:
Error
Not running
Running
Start Time
End Time
Duration
The amount of time the Log Reader Agent has run in this session. The time represents elapsed time if the
Error Message
If a session ended in an error, this field displays the last error message logged by the Log Reader Agent. If a
Action Message
All informational messages and error messages that the Log Reader Agent has logged during the selected
session.
Action Time
See Also
Queue Reader Agent
Warehouse
The Queue Reader Agent dialog box displays detailed information on the Queue Reader Agent, including status,
history, informational messages, and any error messages.
Options
Select which Queue Reader Agent sessions to view from the View menu, and then select a specific session in the
grid labeled Sessions of the Queue Reader Agent. Detailed information on this session is displayed in the grid
labeled Actions in the selected session. If the selected session ended in an error, the text area labeled Error
details or message of the selected session is also displayed.
View
Select which Queue Reader Agent sessions to view. The Queue Reader Agent typically runs continuously, therefore
there might be only one session to view.
Status
The status of the Queue Reader Agent. The following list shows the possible status values:
Error
Not running
Running
Start Time
End Time
Duration
The amount of time the Queue Reader Agent has run in this session. The time represents elapsed time if the
Error Message
If a session ended in an error, this field displays the last error message logged by the Queue Reader Agent. If
a session did not end in an error, this field is blank.
Action Message
All informational messages and error messages that the Queue Reader Agent has logged during the selected
session.
Action Time
See Also
Snapshot Agent
Warehouse
The Snapshot Agent dialog box displays detailed information on the Snapshot Agent, including status, history,
Options
Select which Snapshot Agent sessions to view from the View menu, and then select a specific session in the grid
labeled Sessions of the Snapshot Agent. Detailed information on this session is displayed in the grid labeled
View
Select which Snapshot Agent sessions to view.
Status
Error
Not running
Completed
Start Time
End Time
Duration
The amount of time the Snapshot Agent has run in this session. The time represents elapsed time if the
Error Message
If a session ended in an error, this field displays the last error message logged by the Snapshot Agent. If a
Action Message
All informational messages and error messages that the Snapshot Agent has logged during the selected
session.
Action Time
Is displayed only if the selected session displays a value of Error in the Status column. This text area displays
See Also
Filter Settings
Warehouse
The Filter Settings dialog box lets you define filters for grids in Replication Monitor. For example, to show only
those subscriptions that are active on the All Subscriptions tab, select Status from the Column Name column,
Equals from the Operator column, and Active from the Value1 column. After you define a filter that is based one
or more columns, the filter is applied so that the grid displays only the subset of rows that match the filter criteria.
Options
Column Name
Select the name of the column on which you want to filter. You can base a filter on one or more columns.
Operator
Select an operator for the filter, such as Less than or Equal to.
Value1 and Value2
Enter or select a value for the filter. Most operators only require a value in the Value1 column, but the Between
and Not Between operators also require a value in the Value2 column.
Clear Filter
Click this button to clear all filters that have been defined. To remove a single filter, select the filter row and press
the Delete key.
See Also
Sort Columns
Warehouse
The Sort Columns dialog box lets you sort grids in Replication Monitor based on one or more columns. (You can
also sort on a single column by clicking the column header in the Replication Monitor grid). For example, to sort
subscriptions on the All Subscriptions tab based on status and then connection type, follow these steps:
1. In the first row of the grid, select Status from the Column Name column and a value from the Sort Order
column
2. In the second row of the grid, select Connection Type from the Column Name column, and a value from
the Sort Order column.
Options
Column Name
The name of the column on which you want to sort. You can sort on one or more columns. You cannot sort on the
Current Average Performance or Current Worst Performance columns on the Publications tab, because of
the way in which these column values are calculated.
Sort Order
Specify a value of Ascending or Descending.
Clear All
Remove all rows from the sorting grid. To remove a single row, select the row and press the Delete key.
See Also
Warehouse
This section provides information on the following pages of the Configure Distribution Wizard:
Distributor
Snapshot Folder
Publishers
Distributor Password
See Also
Distributor
Warehouse
The Distributor page appears in the Configure Distribution Wizard and in the New Publication Wizard. The
Distributor is a server that contains the distribution database and stores metadata and history data for all types of
replication. The Distributor also stores transactions for transactional replication. The Distributor can be the same
server as the Publisher (a local Distributor) or it can be a separate server from the Publisher (a remote Distributor).
The role of the Distributor varies, depending on which type of replication you implement. In general, its role is
much greater for transactional replication than it is for merge replication and snapshot replication. Merge and
snapshot replication typically use a local Distributor, but transactional replication on a very busy system can benefit
from using a remote Distributor.
The Distributor uses these additional resources on the server where it is located:
Additional disk space if the snapshot files for the publication are stored on it (which they typically are).
Additional disk space to store the distribution database.
Additional processor usage by replication agents for push subscriptions running on the Distributor.
The server you select as the Distributor should have adequate disk space and processor power to support
replication and any other activities on that server.
Options
'<ServerName>' will act as its own Distributor; SQL Server will create a distribution database and log
Select this option to configure the server you are connected to as a Distributor.
Use the following server as the Distributor (Note: the server you select must already be configured as a
Distributor)
Select this option and then click on the name of a server below to configure another server as the Distributor.
Add
If the server you want to use as a Distributor is not listed, click Add to identify the server and add it to the list.
NOTE
To use a remote server as the Distributor, the remote server must already be configured as a Distributor. The server against
which this wizard is running must be enabled as a Publisher on that Distributor.
See Also
Snapshot Folder
Warehouse
The Snapshot Folder page appears in the Configure Distribution Wizard and in the New Publication Wizard. The
location you specify for the snapshot folder will be used as the default for all Publishers enabled in this wizard (the
default snapshot folder does not apply to Publishers that are later enabled using the Distributor Properties dialog
box). You can override this default for any Publisher on the Publishers page of the Configure Distribution Wizard
or the Distributor Properties dialog box.
The snapshot folder is simply a directory that you have designated as a share; agents that read from and write to
this folder must have sufficient permissions to access it. For more information about securing the folder
appropriately, see Secure the Snapshot Folder. Prior to implementing replication, test that the replication agents
will be able to connect to the snapshot folder. Log on under the account that will be used by each agent and then
attempt to access the snapshot folder.
Options
Snapshot folder
Enter the path for the folder where you want snapshot files stored.
NOTE
Microsoft recommends that you use a network share as a snapshot folder location. Local paths (those starting with a drive
letter, such as C:\) are not accessible to agents on other computers.
See Also
Warehouse
The distribution database stores metadata and history data for all types of replication, and transactions for
In many cases, a single distribution database is sufficient. However, if multiple Publishers use a single Distributor,
consider creating a distribution database for each Publisher. Doing so ensures that the data flowing through each
distribution database is distinct. You can specify one distribution database for the Distributor using the Configure
Distribution Wizard. If necessary, specify additional distribution databases in the Distributor Properties dialog
box.
Options
Distribution database name
Enter a name for the distribution database. The default name for the distribution database is 'distribution'. If you
specify a name, the name can be a maximum of 128 characters, must be unique within an instance of Microsoft
SQL Server, and must conform to the rules for identifiers. For more information, see Database Identifiers.
Folder for the distribution database file and Folder for the distribution database log file
Enter the path for the distribution database and log files. Paths must refer to disks that are local to the Distributor
and begin with a local drive letter and colon (for example, C:). Mapped drive letters and network paths are not valid.
NOTE
You can decrease the time it takes to write transactions and improve the performance of replication by placing the
distribution database log on a separate disk drive from the distribution database.
See Also
Publishers
Warehouse
You can give permission for other Publishers to use this Distributor. Be aware that enabling a Publisher to use this
server as its remote Distributor does not make that server a Publisher. You must connect to the Publisher, configure
it for publishing, and choose this server as the Distributor. You can configure the Publisher and choose a Distributor
through the New Publication Wizard.
The servers you select as Publishers will use the distribution database specified on the Distribution Database
page of this wizard. If you want to use a different distribution database, do not enable the Publisher at this time.
Instead, use the Distributor Properties dialog box to add Publishers after you complete the Configure Distribution
Wizard.
Options
Publishers
Select the servers that are allowed to use this Distributor. Click the properties button (...) next to a Publisher to view
and set additional properties.
Add
If the server you want to allow is not listed, click Add to add a Microsoft SQL Server Publisher or Oracle Publisher
to the list of available Publishers.
See Also
Distributor Password
Warehouse
If, on the Publishers page of this wizard, you enabled one or more Publishers to use this server as a remote
Distributor, you must specify a password for the connection replication makes between the Publisher and the
remote Distributor using the distributor_admin login. The same password must be entered for each Publisher
that uses this remote Distributor on the Administrative Password page of the New Publication Wizard or the
Configure Distribution Wizard. For more information on security for Distributors, see Secure the Distributor.
Options
Password
Enter a strong password for the connection between the Publisher and the remote Distributor.
Confirm Password
Re-enter the password to confirm it was entered correctly.
See Also
Warehouse
This section provides information on the following pages of the New Publication Wizard:
Oracle Publisher
Administrative Password
Publication Type
Subscriber Types
Agent Security (New Publication Wizard)
Articles
Article Issues
Filter Table Rows
Add or Edit Filter
Add or Edit Join
Generate Filters
Snapshot Agent (New Publication Wizard)
See Also
Oracle Publisher
Warehouse
Beginning with Microsoft SQL Server 2005, SQL Server allows you to publish data from an Oracle database using
snapshot and transactional replication. For more information, see Oracle Publishing Overview.
The Oracle Publisher must use a remote SQL Server Distributor; this wizard must be run on that server after the
necessary Oracle networking software has been installed and tested. For more information, see Configure an
Oracle Publisher.
IMPORTANT
If another administrator configured the Oracle database as a Publisher, after clicking Next you will be prompted to enter the
password for the replication login used to connect to the Oracle database. SQL Server will then create a mapping between
your login and the linked server connection to the Oracle database. You will not be required to enter a password for
subsequent connections to the Oracle database.
Options
Oracle Publishers
Select an Oracle Publisher from the list. This list contains Oracle Publishers that have previously been configured to
use the server against which the wizard is running as their Distributor. If the list is empty, or the Oracle Publisher
you want to use is not in the list, click Add Oracle Publisher.
Add Oracle Publisher
Click to launch the Distributor Properties dialog box. In this dialog box, click Add, and then click Add Oracle
Publisher. In the Connect to Server dialog box, specify the Oracle server name, and the login and password for
the replication administrative user schema. For more information, see Connect to Server (Oracle), Login.
NOTE
If the server against which the wizard is running has not yet been configured as a Distributor, you are prompted to configure
it now.
See Also
Create a Publication from an Oracle Database
Administrative Password
Warehouse
If, on the Distributors page of this wizard, you selected a remote Distributor for this Publisher, you must enter a
password for the connection replication makes between the Publisher and the Distributor using the
distributor_admin login. The password must match the password specified on the Distributor Password page of
the Configure Distribution Wizard or the Publishers page of the Distributor Properties dialog box.
Options
Password
Enter the password for the connection between the Publisher and the remote Distributor.
Confirm Password
Re-enter the password to confirm it was entered correctly.
See Also
Warehouse
The publication database is the database on the Publisher that is the source of data and database objects to be
replicated. Each publication database used in replication must be enabled. The database is enabled when a member
of the sysadmin fixed server role:
Creates a publication on that database using the New Publication Wizard.
Selects the database in the Publisher Properties dialog box.
Executes sp_replicationdboption and sets the option publish (for snapshot or transactional publications)
or merge publish (for merge publications) to True.
Options
Databases
Select the name of the database that contains the data and database objects that you want to publish.
See Also
sp_replicationdboption (Transact-SQL)
Publication Type
Warehouse
Replication provides the following types of publications:
Snapshot publication
Transactional publication
Merge publication
Which type or types of replication you choose for your application depends on the physical replication
environment, the type and quantity of data to be replicated, and whether or not data is updated at the
Subscriber. The physical environment includes the number and location of computers involved in replication,
and whether these computers are clients (workstations, laptops, or handheld devices) or servers. For more
information, see Types of Replication.
Options
Publication type
Select the appropriate replication type for this publication.
See Also
Subscriber Types
Warehouse
Merge replication allows you to specify the types of Subscribers that a publication must support. Selecting
Subscriber types sets the publication compatibility level, which determines which features can be used by a
publication.
After a publication snapshot is created, the publication compatibility level can be increased (made more restrictive)
on the General page of the Publication Properties dialog box; the compatibility level cannot be decreased.
Options
Select each Subscriber type that this publication must support.
SQL Server 2017
The publication can use all features.
SQL Server Compact
The publication requires snapshot files to be in character format (this is handled automatically by the Snapshot
Agent). SQL Server Compact also has a number of restrictions not related to compatibility level.
If this option is selected, the Web synchronization option is enabled for the publication. For more information about
Web synchronization, see Web Synchronization for Merge Replication.
See Also
Agent Security (New Publication Wizard)
Warehouse
The Agent Security page allows you to specify the accounts under which the following agents run and make
connections to the computers in a replication topology:
The Snapshot Agent for all publications.
The Log Reader Agent for all transactional publications.
The Queue Reader Agent for transactional publications that allow updatable subscriptions. The Microsoft
SQL Server Agent job for this agent is created if you specified Transactional publication with updatable
subscriptions on the Publication Type page, regardless of the type of updatable subscriptions you use.
For more information about updatable subscriptions, see Updatable Subscriptions for Transactional
Replication.
For information about permissions required by agents and best practices for replication security, see
Replication Agent Security Model and Replication Security Best Practices.
Options
Snapshot Agent
Displayed for all publications. Click Security Settings to specify security settings in the Snapshot Agent Security
dialog box.
Click Help on the Snapshot Agent Security dialog box for more information about the permissions required for
accounts used by the Snapshot Agent.
Log Reader Agent
Displayed for all transactional publications. Click Security Settings to specify security settings in the Log Reader
Agent Security dialog box.
Click Help on the Log Reader Agent Security dialog box for more information about the permissions required
for accounts used by the Log Reader Agent.
NOTE
There is one Log Reader Agent for each database that is published using transactional replication. If a transactional
publication already exists in the database, the security settings are read-only. You can change the settings in the Publication
Properties dialog box, but changes affect all transactional publications in the database.
Queue Reader Agent

Displayed for transactional publications that allow updatable subscriptions. Click Security Settings to specify
security settings in the Queue Reader Agent Security dialog box. A Queue Reader Agent job is created when this
wizard completes; it does not depend on you creating any queued updating subscriptions. If you do not plan to
create any queued updating subscriptions, you can disable the job. Right-click the job (named in the form:
[<Publisher>].<integer>.) in the SQL Server Agent Jobs folder, and then click Disable.
Click Help on the Queue Reader Agent Security dialog box for more information about the permissions required
for accounts used by the Queue Reader Agent.
NOTE
There is one Queue Reader Agent for each distribution database (and all Publishers that it serves). If a transactional
publication that allows queued updating subscriptions already exists on any of the Publishers that use a given distribution
database, the security settings are read-only. You can change the account under which the Queue Reader Agent runs and
makes connections in the Distributor Properties dialog box, but changes affect publications at all Publishers that use the
See Also
Create an Updatable Subscription to a Transactional Publication
Manage Logins and Passwords in Replication
Articles
Warehouse
On the Articles page, you specify which database objects to include as articles in the publication. If you are
publishing a database object that depends on one or more other database objects, you must publish all referenced
objects. For example, if you publish a view that depends on a table, you must publish the table also.
Objects that cannot be published have a red icon next to them, with an explanation in the information panel at the
bottom of the wizard page. The following objects cannot be published:
Encrypted objects.
Tables without primary keys cannot be published in transactional publications.
Tables cannot be published in both a merge publication and a transactional publication enabled for queued
updating subscriptions. For more information about publishing an article in more than one publication, see
the "Publishing Tables in More Than One Publication" section in Publish Data and Database Objects.
Oracle Publishers
There are additional considerations for Oracle Publishers:
For a list of objects that can be published from Oracle, see Design Considerations and Limitations for Oracle
Publishers. Objects that cannot be published are not displayed.
For a list of data types that can be published, see Data Type Mapping for Oracle Publishers. Columns with
data types that cannot be published are not displayed.
Column Filters
Filter columns on this page by expanding a table in the Objects to publish pane and then selecting only the
columns required (rows can be filtered in the Filter Table Rows page of this wizard). Filtering columns is useful for
a number of reasons, including security (preventing sensitive data from being replicated) and performance
(avoiding replication of large binary large object (BLOB) columns, for example). For more information about
column filtering, including a list of column types that cannot be filtered, see Filter Published Data.
Options
The Objects to publish pane allows you to:
View all objects available for replication.
Include an object in a publication by selecting the check box next to that object.
Include all objects of a particular type (such as a table) in the publication by selecting the check box next to
that object type (such as Tables).
Expand table nodes to see the columns in the table.
Filter table columns out of a publication by clearing the check box next to the column.
Right-click an object in the pane to see a menu of commands for that object.
Article Properties
Click Article Properties, and then click one of the following:
Click Set Properties of Highlighted <ObjectType> Article to launch the Article Properties -
<ObjectName> dialog box; property changes made in this dialog box are applied only to the object that is
highlighted in the object pane on the Articles page.
Click Set Properties of All <ObjectType> Articles, to launch the Properties for All <ObjectType>
Articles dialog box; property changes made in this dialog box are applied to all objects of that type in the
object pane on the Articles page, including ones not yet selected for publication.
NOTE
Property changes made in the Properties for All <ObjectType> Articles dialog box override any made previously
in the Article Properties - <ObjectName> dialog box. If, for example, you want to set a number of defaults for all
articles of an object type, but also want to set some properties for individual objects, set the defaults for all articles
first. Then set the properties for the individual objects.
Highlighted table is download-only

Merge replication only. Microsoft SQL Server 2005 and later versions only. Select to specify that changes are
disallowed at the Subscriber if a client subscription is used. Because download-only articles cannot be
updated at the Subscriber, tracking metadata is not sent to Subscribers. This can lead to reduced storage on
the Subscribers and a performance benefit, especially if the network connection is slow. This option
corresponds to a value of Download-only to Subscriber, prohibit Subscriber changes for the option
Synchronization direction in the Article Properties dialog box. For more information, see Optimize
Merge Replication Performance with Download-Only Articles.
Show only checked objects in the list
Select this check box to show only those articles that are selected in the object pane.
See Also
Article Issues
Warehouse
The Article Issues page lists conditions that have been found for articles and any changes required as a result of
these conditions. The following table lists possible issues and the actions required to ensure replication and existing
applications function properly.
ARTICLE ISSUE DETAILS ACTION REQUIRED
Uniqueidentifier columns will be added Replication requires a column of data Replication automatically adds a column
to tables. type uniqueidentifier for all articles in of data type uniqueidentifier to
a merge publication or a transactional published tables that do not have one
publication that allows updating when the first snapshot is generated.
subscriptions. You must ensure that INSERT and
UPDATE statements that reference
these tables use column lists. Also
ensure that there is sufficient space on
disk for the additional column.
IDENTITY columns require the NOT FOR Replication requires that all IDENTITY Applies to publications created on
REPLICATION option. columns use the NOT FOR Publishers running Microsoft SQL
REPLICATION option. If a published Server 2000 and earlier. You must
IDENTITY column does not use this specify the NOT FOR REPLICATION
option, INSERT commands might not property for all IDENTITY columns.
replicate properly.
IDENTITY property not transferred to This publication does not allow updates Applies to publications created on
Subscribers. at Subscribers. When IDENTITY columns Publishers running SQL Server 2000
are transferred to the Subscriber, the and earlier. No action is necessary.
IDENTITY property is not be transferred.
For example, a column defined as INT
IDENTITY at the Publisher is defined as
INT at the Subscriber.
Tables referenced by views are required. Microsoft SQL Server requires that all Use the Back button to navigate to the
tables referenced by views and indexed Articles page. Add any required
views that are published be available at objects.
the Subscriber. If the referenced tables
are not published as articles in this
publication, they must be created at the
Subscriber manually.
Objects referenced by stored SQL Server requires that all objects Use the Back button to navigate to the
procedures are required. referenced by published stored Articles page. Add any required
procedures, such as tables and user- objects.
defined functions, be available at the
Subscriber. If the referenced objects are
not published as articles in this
publication, they must be created at the
Subscriber manually.
See Also
Filter Table Rows
Warehouse
The Filter Table Rows page allows you to:
Apply static row filters to table articles in snapshot, transactional, and merge publications.
Apply parameterized row filters to table articles in merge publications.
Use join filters to extend filters on merge table articles to related table articles.
For more information about filtering options, see Filter Published Data. Filtering can be changed in the Filter
Rows page of the Publication Properties dialog box.
To maximize application performance and reduce the amount of remote storage required, or to restrict the
availability of certain data to specific Subscribers, you should publish only the data required. Your
publication can include both unfiltered and filtered tables. For example, you could include the complete
(unfiltered) table of company products and use row filters to provide a filtered table of customers for a
specific region. By filtering published data, you can:
Minimize the amount of data sent over the network.
Reduce the amount of storage space required at the Subscriber.
Customize publications and applications based on individual Subscriber requirements.
Avoid or reduce conflicts if Subscribers are updating data, because different data partitions can be sent to
different Subscribers (no two Subscribers will be updating the same data values).
Avoid transmitting sensitive data. Row filters and column filters can be used to restrict a Subscriber's access
to data. For merge replication, there are security considerations if you use a parameterized filter that
includes HOST_NAME(). For more information, see the section "Filtering with HOST_NAME()" in
A filter must not include the rowguidcol used by replication to identify rows. By default this is the column
added at the time you set up merge replication and is named rowguid.
Options
Filtered Tables
This pane is populated with filters as you add them to table articles in the publication. Tables with row filters are
shown as top-level nodes in the pane. For merge publications, tables to which filtering has been extended through
a join filter are shown as child nodes.
Add
Click Add to launch a dialog box that enables you to filter table articles. Clicking Add for a snapshot or
transactional publication launches a dialog box immediately. Clicking Add for a merge publication displays three
choices: Add Filter; Add Join to Extend the Selected Filter; Automatically Generate Filters.
Select Add Filter to launch the Add Filter dialog box. This dialog box allows you to apply row filters to a
table article. In the Add Filter dialog box, you could, for example, specify that a table with customer data
should only contain data on French customers when it is replicated to Subscribers.
Select Add Join to Extend the Selected Filter to launch the Add Join dialog box. The Add Join dialog box
allows you to extend a row filter so that it filters data in tables related to the table with the row filter. For
example, if a customer table is filtered so that it only contains data on French customers and there is a
related table for customer orders, you can define a join between the two tables so that the orders table only
includes orders from French customers.
NOTE
This option is available only if you first select the base table of the join in the filter pane.
Select Automatically Generate Filters to launch the Generate Filters dialog box. This dialog box allows
you to define a row filter on one table in a merge publication that replication automatically extends to other
tables that are related through foreign key relationships. For example, a publication could include three
tables: a customer table, an orders table (with a foreign key to the customer table), and an order details table
(with a foreign key to the orders table). Define a row filter on the customer table, and replication will extend
it to the other tables.
NOTE
When filters are automatically generated by replication, any existing filters on the publication are deleted. To include
both filters generated automatically and ones specified manually, generate filters first. You can only specify one set of
automatically generated filters for each publication.
Edit
Select a row filter or join filter in the filter pane and click Edit to launch the Edit Filter or Edit Join dialog
box.
Delete
Select a row filter or join filter in the filter pane and click Delete to delete the filter.
Find Table
Merge publications with join filters only. Click Find Table to find a table in a complex filter tree. In a
database with complex relationships, a table can be joined to multiple tables, and therefore can appear in
more than one place in the filter tree.
The actual table appears in only one place in the tree, and in other places, the table is represented by a
shortcut. A shortcut to a table is only a reference to the table; it does not show the child nodes of the table. A
shortcut node is marked with a shortcut arrow, and expanding that node shows the text Click Find Table to
see table for <tablename>.
Select a shortcut node in the pane and click Find Table. The pane is expanded and the table is highlighted. If
you click Find Table without a shortcut node selected, a Find Table dialog box is launched.
Filter
Contains the Transact-SQL definition for the filter selected in the filter pane.
See Also
Join Filters
Add or Edit Filter
Warehouse
The Add Filter and Edit Filter dialog boxes allow you to add and edit static row filters and parameterized row
filters.
NOTE
Editing a filter in an existing publication requires a new snapshot for the publication. If a publication has subscriptions, the
subscriptions must be reinitialized. For more information about property changes, see Change Publication and Article
Properties.
All publication types can include static filters; merge publications can also include parameterized filters. A static
filter is evaluated when the publication is created: all Subscribers to the publication receive the same data. A
parameterized filter is evaluated during replication synchronization: different Subscribers can receive different
partitions of data based on the login or computer name of each Subscriber. Click the Example statements link in
the dialog box to see examples of each type of filter. For more information about filtering options, see Filter
Published Data.
Using row filters, you can specify a subset of rows to be published from a table. Row filters can be used to eliminate
rows that users do not need to see (such as rows that contain sensitive or confidential information), or to create
different partitions of data that are sent to different Subscribers. Publishing different partitions of data to different
Subscribers can also help avoid conflicts that would otherwise be caused by multiple Subscribers updating the
same data.
Options
This dialog box involves a two-step process for transactional and snapshot publications and a three-step process
for merge publications. All publication types require you to select a table to be filtered and one or more columns to
be included in the filter; the filter is defined as a standard WHERE clause.
1. Select the table to filter
If you are editing an existing filter, the table selection cannot be changed. If you are adding a new filter, select
a table from the drop-down list box. Tables appear in the list box only if they were selected on the Articles
page and do not already have a row filter. If a table has a row filter and you want to define a new one:
a. Click Cancel on the Add Filter dialog box.
b. Select the table in the filter pane on the Filter Table Rows page and click Edit.
c. Edit an existing filter in the Edit Filter dialog box.
2. Complete the filter statement to identify which table rows Subscribers will receive
Define a new filter statement or edit an existing one. The Columns list box lists all the columns that you are
publishing from the table you selected in Select the table to filter. The Filter statement text area includes
the default text, which is in the form of:
SELECT <published_columns> FROM [schema].[tablename] WHERE
This text cannot be changed; type the filter clause after the WHERE keyword using standard Transact-SQL
syntax. If the Publisher is an Oracle Publisher, the WHERE clause must be compliant with Oracle query
syntax. Avoid using complex filters when possible. Both static and parameterized filters increase processing
time for publications; therefore you should keep filter statements as simple as possible.
IMPORTANT
For performance reasons, we recommended that you not apply functions to column names in parameterized row filter
clauses for merge publications, such as LEFT([MyColumn]) = SUSER_SNAME() . If you use HOST_NAME in a filter
clause and override the HOST_NAME value, it might be necessary to convert data types using CONVERT. For more
information about best practices for this case, see the section "Overriding the HOST_NAME() Value" in the topic
3. Specify how many subscriptions will receive data from this table
Microsoft SQL Server 2005 and later versions only; merge replication only. Merge replication allows you to
specify the type of partitions that are best suited to your data and application. If you select A row from this
table will go to only one subscription, merge replication sets the nonoverlapping partitions option.
Nonoverlapping partitions work in conjunction with precomputed partitions to improve performance, with
nonoverlapping partitions minimizing the upload cost associated with precomputed partitions. The
performance benefit of nonoverlapping partitions is more noticeable when the parameterized filters and join
filters used are more complex. If you select this option, you must ensure that the data is partitioned in such a
way that a row cannot be replicated to more than one Subscriber. For more information, see the section
"Setting 'partition options'" in the topic Parameterized Row Filters.
After you have added or edited a filter, click OK to save changes and close the dialog box. The filter you
specified is parsed and run against the table in the SELECT clause. If the filter statement contains syntax
errors or other problems, you are notified and are able to edit the filter statement.
See Also
Join Filters
Add or Edit Join
Warehouse
The Add Join and Edit Join dialog boxes allow you to add and edit join filters for merge publications.
NOTE
Editing a filter in an existing publication requires a new snapshot for the publication. If a publication has subscriptions, the
subscriptions must be reinitialized. For more information about property changes, see Change Publication and Article
Properties.
A join filter allows a table to be filtered based on how a related table in the publication is filtered. Typically a parent
table is filtered using a parameterized row filter; then one or more join filters are defined in much the same way
that you define a join between tables. The join filters extend the row filter so that the data in the related tables is
replicated only if it matches the join filter clause.
Join filters typically follow the primary key/foreign key relationships defined for the tables to which they are
applied, but they are not limited strictly to primary key/foreign key relationships. The join filter can be based on any
logic that compares related data in two article tables.
IMPORTANT
Join Filters can involve an unlimited number of tables, but filters with a large number of tables can impact performance during
merge processing. If you are generating join filters of five or more tables, consider other solutions: do not filter tables that are
small, not subject to change, or are primarily lookup tables. Use join filters only between tables that must be partitioned
among Subscribers.
Options
This dialog box involves a three-step process to create a join filter between two tables. Creating more than one join
filter requires more than one pass through the dialog box.
1. Verify filtered table and select the joined table
If you are adding a new join, verify that the table in the Filtered table text box is correct (if it is not
correct, click Cancel, select the correct table on the Filter Table Rows page, and click Add Join to
return to this dialog box). Then select a table from the Joined table drop-down list box.
If you are editing an existing join, the table names will be specified already and cannot be changed. To
change the tables involved in the join, you must delete the existing join filter on the Filter Table
Rows page and create a new join between different tables.
2. Create the join statement
If you are adding a new join, select either Use the builder to create the statement or Write the
join statement manually. If you begin writing the join manually, you cannot use the builder.
If you select to use the builder, use the columns in the grid (Conjunction, Filtered table column,
Operator, and Joined table column) to build a join statement. Each column in the grid contains a
drop-down list box, allowing you to select two columns and an operator (=, <>, <=, <, >=, >, like).
The results are displayed in the Preview text area. If the join involves more than one pair of columns,
select a conjunction (AND or OR) from the Conjunction column, and then enter two more columns
and another operator.
If you select to write the statement manually, write the join statement in the Join statement text area.
Use the Filtered table columns list box and Joined table columns list box to drag and drop
columns to the Join statement text area.
If you are editing an existing join, you must make edits manually.
3. Specify join options
If the column on which you join in the filtered table is unique, select Unique key. The merge process
has special performance optimizations available if the column is unique.
Cau t i on
Selecting this option indicates that the relationship between the child and parent tables in a join filter
is one to one or one to many. Only select this option if you have a constraint on the joining column in
the parent table that guarantees uniqueness. If the option is set incorrectly, non-convergence of data
can occur.
Microsoft SQL Server 2005 and later versions only. By default, merge replication processes changes
on a row-by-row basis during synchronization. To have related changes processed as a unit, select
Logical record. This option is available only if the article and publication requirements for using
logical records are met. For more information, see the section "Considerations for Using Logical
Records" in Group Changes to Related Rows with Logical Records.
After you have added or edited a filter, click OK to save changes and close the dialog box. The filter you
specified is parsed and run against the table in the SELECT clause. If the filter statement contains syntax
errors or other problems, you will be notified and will be able to edit the filter statement.
See Also
Join Filters
Generate Filters
Warehouse
The Generate Filters dialog box allows you to define a row filter on one table in a merge publication; replication
then automatically extends the filter to other tables that are related through foreign key relationships. For example,
if you define a filter on a customer table so that it only contains data on French customers, replication extends that
filter so that related orders and order details tables contain only information related to French customers.
Options
This dialog box involves a three-step process to create a row filter on a table. The filter is then extended to the
tables related to the filtered table through primary key and foreign key relationships. For example, given the three
tables Customer, SalesOrderHeader, and SalesOrderDetail, with a relationship between Customer and
SalesOrderHeader, and a relationship between SalesOrderHeader and SalesOrderDetail, apply a row filter to
Customer, and replication extends that filter to SalesOrderHeader and SalesOrderDetail.
1. Select the table to filter.
Select a table from the drop-down list box. Tables appear in the list box only if they were selected on the
Articles page.
2. Complete the filter statement to identify which table rows Subscribers will receive.
Define a new filter statement. The Columns list box lists all the columns that you are publishing from the
table you selected in Select the table to filter. The Filter statement text area includes the default text,
which is in the form of:
SELECT <published_columns> FROM [tableowner].[tablename] WHERE
This text cannot be changed; type the filter clause after the WHERE keyword using standard Transact-SQL
syntax.
IMPORTANT
For performance reasons, we recommended that you not apply functions to column names in parameterized row filter
clauses, such as LEFT([MyColumn]) = SUSER_SNAME() . If you use HOST_NAME in a filter clause and override the
HOST_NAME value, it might be necessary to convert data types using CONVERT. For more information about best
practices for this case, see the section "Overriding the HOST_NAME() Value" in the topic Parameterized Row Filters.
3. Specify how many subscriptions will receive data from this table.
Microsoft SQL Server 2005 and later versions only. Merge replication allows you to specify the type of
partitions that are best suited to your data and application. If you select A row from this table will go to
only one subscription, merge replication sets the nonoverlapping partitions option. Nonoverlapping
partitions work in conjunction with precomputed partitions to improve performance, with nonoverlapping
partitions minimizing the upload cost associated with precomputed partitions. The performance benefit of
nonoverlapping partitions is more noticeable when the parameterized filters and join filters used are more
complex. If you select this option, you must ensure that the data is partitioned in such a way that a row
cannot be replicated to more than one Subscriber. For more information, see the section "Setting 'partition
options'" in the topic Parameterized Row Filters.
After you have added a filter, click OK to exit and close the dialog box. The filter you specified is parsed and
run against the table in the SELECT clause. If the filter statement contains syntax errors or other problems,
you will be notified and will be able to edit the filter statement.
After the statement is parsed, replication creates the necessary join filters. If you have not yet configured the
Distributor for the Publisher against which this wizard is running, you are prompted to configure it.
See Also
Join Filters
Snapshot Agent (New Publication Wizard)
Warehouse
The Snapshot Agent creates files containing the publication schema and data that are used to initialize new
subscriptions. By default, the Snapshot Agent runs immediately after the publication is created in the New
Publication Wizard. Subsequently, the agent runs according to a schedule you specify. Whether the agent creates
new snapshot files each time it runs depends on the type of replication and options chosen. For more information,
see Create and Apply the Snapshot.
For merge publications that use parameterized filters, you must create a snapshot for each partition of data after
the publication snapshot has completed. For more information, see Snapshots for Merge Publications with
Parameterized Filters.
Options
Create a snapshot immediately (merge replication) or Create a snapshot immediately and keep the
snapshot available to initialize subscriptions (transactional replication)
Select this check box to create a snapshot immediately after the New Publication Wizard is completed. Clear this
check box if you plan to change snapshot properties in the Publication Properties dialog box before generating a
snapshot, or if you will initialize the Subscriber without a snapshot. For more information, see Initialize a
NOTE
The wizard might prompt for a connection to the Distributor in order to start the appropriate job for the Distribution Agent
or Merge Agent.
Schedule the Snapshot Agent to run at the following times

Accept the default schedule for running the Snapshot Agent, or click Change to specify a schedule.
See Also
This section provides information on the following pages of the New Subscription Wizard:
<AgentName> Agent Location
Subscribers
Add Non-SQL Server Subscriber
<AgentName> Agent Security
Login for Updatable Subscriptions
Initialize Subscriptions
Web Server Information
Subscription Type
HOST_NAME Values
See Also
<AgentName> Agent Location
Warehouse
The Merge Agent (for merge subscriptions) and the Distribution Agent (for transactional and snapshot
subscriptions) run at the Distributor or at the Subscriber. If the agent runs at the Distributor, the subscription is
referred to as a push subscription; if the agent runs at the Subscriber, it is referred to as a pull subscription. For
more information about push and pull subscriptions, see Subscribe to Publications. All subscriptions created in this
pass through the wizard will be of the selected type. To create subscriptions of both types, you must run the wizard
twice.
NOTE
Subscription type cannot be changed after a subscription is created.
See Also
Subscribers
Warehouse
Specify the Microsoft SQL Server or non- SQL Server Subscribers that will receive a subscription to the selected
publication.
Options
Subscribers
Select the check box in the grid to enable the corresponding SQL Server or non- SQL Server data source as a
Subscriber to the publication chosen on the Publication page. If the Subscriber is not listed, click Add Subscriber
or Add SQL Server Subscriber.
Subscription database
The information displayed in and actions available from this column depend on the type of Subscriber listed in the
Subscribers column:
For SQL Server Subscribers, select a subscription database from the Subscription Database list or create a
new database by selecting the New database command from the same list.
NOTE
If you are enabling the Publisher as a Subscriber, the subscription database must be different from the publication
database.
For non- SQL Server Subscribers, the subscription database is not displayed. Specify the database, along
with other connection information, in the Data source name field of the Add Non-SQL Server dialog box.
This dialog box is available by clicking Add Subscriber and then clicking Add Non-SQL Server Subscriber.
Add Subscriber
Add a server to the list of servers that can be enabled as Subscribers. This button is displayed when all of the
following conditions are true:
The publication you selected is a snapshot or transactional publication that does not support updating
subscriptions.
NOTE
If the publication you are subscribing to has SQL Server subscriptions and the publication is not already enabled for
non- SQL Server Subscribers, you cannot add a non- SQL Server subscription.
The subscription is a push subscription.

The Publisher of the selected publication is Microsoft SQL Server 2005 or later.
Clicking Add Subscriber shows a menu with two choices: Add SQL Server Subscriber and Add Non-SQL
Server Subscriber. Click Add Non-SQL Server Subscriber to add an Oracle or IBM DB2 Subscriber.
Add SQL Server Subscriber
Add a server to the list of servers that can be enabled as Subscribers. This button is displayed when one or
more of the following conditions is true:
The publication you selected is a merge publication, or a snapshot or transactional publication that supports
The subscription is a pull subscription.
The Publisher of the selected publication is earlier than SQL Server 2005. For earlier versions, the button is
displayed only if one or more of the following conditions is true:
You are a member of the sysadmin fixed server role at the Publisher.
The Subscriber has been added on the Subscribers page of the Publisher Properties dialog box.
The publication allows anonymous subscriptions.
See Also
Add Non-SQL Server Subscriber
Warehouse
Replication supports creating push subscriptions to snapshot and transactional publications for Oracle and IBM
DB2 Subscribers.
Options
Type of Subscriber to add
Select an Oracle Subscriber or IBM DB2 Subscriber. For more information about support for these Subscribers, see
Non-SQL Server Subscribers.
Data source name
The name used to locate the database on a network. Replication produces a connection string for the database
using the data source name, combined with the login, password, and any connection options you specify in the
Distribution Agent Security page in this wizard.
NOTE
The data source name and connection string are not validated by Microsoft SQL Server until the Distribution Agent attempts
to initialize the subscription.
See Also
Create a Subscription for a Non-SQL Server Subscriber
<AgentName> Agent Security
Warehouse
The <AgentName> Agent Security page allows you to specify the accounts under which the Distribution Agent
(for transactional and snapshot replication) or Merge Agent (for merge replication) run and make connections to
the computers in a replication topology. For information on permissions required by agents and best practices for
replication security, see Replication Agent Security Model and Replication Security Best Practices.
Options
Click the properties button (...) in the row for each Subscriber to access the Distribution Agent Security or
Merge Agent Security dialog box. Click Help on the dialog box that is launched for more information on the
permissions required for accounts used by the agents.
After settings have been entered in one of the dialog boxes, connection information for the Subscriber is displayed
in the grid.
Agent for Subscriber
The name of each Subscriber.
Connection to Distributor
Displayed for transactional and snapshot replication. The context under which the connection to the Distributor is
made. Local connections are always made using the context of the Microsoft Windows account under which the
agent runs:
For push subscriptions, the local connection is the connection to the Distributor, so this field will always
display: Impersonate '<Domain>\<Login>' or Impersonate '<Computer>\<Login>' for push
subscriptions.
For pull subscriptions, the connection can also be made under the context of a Microsoft SQL Server login.
The field displays one of the following: Use login '<Login>', Impersonate '<Domain>\<Login>' or
Impersonate '<Computer>\<Login>'. Microsoft recommends that all connections be made using the
context of the Windows account.
Connection to Publisher & Distributor
Displayed for merge replication. The context under which the connections to the Publisher and Distributor
are made. Local connections are always made using the context of the Windows account under which the
agent runs:
For push subscriptions, the local connection is the connection to the Publisher and Distributor, so this field
will always display: Impersonate '<Domain>\<Login>' or Impersonate '<Computer>\<Login>' for
push subscriptions.
For pull subscriptions, the connection can also be made under the context of a SQL Server login. The field
displays one of the following: Use login '<Login>', Impersonate '<Domain>\<Login>' or Impersonate
'<Computer>\<Login>'. Microsoft recommends that all connections be made using the context of the
Windows account.
Connection to Subscriber
The context under which the connection to the Subscriber is made. Local connections are always made using
the context of the Windows account under which the agent runs:
For pull subscriptions, the local connection is the connection to the Subscriber, so this field will always
display: Impersonate '<Domain>\<Login>' or Impersonate '<Computer>\<Login>' for push
subscriptions.
For push subscriptions, the connection can also be made under the context of a SQL Server login. The field
displays one of the following: Use login '<Login>', Impersonate '<Domain>\<Login>' or Impersonate
'<Computer>\<Login>'. Microsoft recommends that all connections be made using the context of the
Windows account.
See Also
Replication Agent Security Model
Warehouse
With transactional replication, replicated data should be treated as read-only; however, you can modify replicated
data at a Microsoft SQL Server Subscriber by using updatable subscriptions. If you need to modify data at the
Subscriber, choose one of the following options depending on your requirements.
UPDATABLE SUBSCRIPTION TYPE REQUIREMENTS
Immediate Updating Publisher and Subscriber must be connected to update data at

the Subscriber.
Queued Updating Publisher and Subscriber do not have to be connected to

update data at the Subscriber. Updates can be made while
offline, and later synchronized between the Publisher and
Subscriber.
Options
Replicate Subscriber changes
Select the check box in the Replicate column for each Subscriber that should be able to make updates. For those
Subscribers that can make updates, select the appropriate option from the drop-down list box in the Commit at
Publisher column:
Select Simultaneously commit changes for an immediate updating subscription.
Select Queue changes and commit when possible for a queued updating subscription.
See Also
Updatable Subscriptions for Transactional Replication
Login for Updatable Subscriptions
Warehouse
For immediate update, if you selected Replicate on the Updatable Subscriptions page of this wizard, you must
specify an account with the Subscriber under which connections to the Publisher are made.
Connections are used by the triggers that fire at the Subscriber, and propagate changes to the Publisher. This
account is required even if you selected Queue changes and commit when possible on the Updatable
Subscriptions page. The New Subscription Wizard by default configures queued updating with the ability to switch
to immediate updating if required.
IMPORTANT!! The account specified for the connection should only be granted permission to insert, update,
and delete data on the views that replication creates in the publication database. It should not be given any
additional permissions. Grant permissions on Views in the publication database named in the form
syncobj_<HexadecimalNumber> to the account you configured at each Subscriber.
There are three options available for the type of connection:

A linked server or remote server that you have already defined.
A linked server that replication creates; the connection is made with the credentials you specify in this
wizard.
A linked server that replication creates; the connection is made with the credentials of the user making the
change at the Subscriber.
The first two options can be specified in this wizard. The last option can only be specified using
sp_link_publication (Transact-SQL); specify a value of 1 for the parameter @security_mode.
Options
Create a linked server that connects using the following SQL Server Authentication login:
Replication creates a linked server using the credentials specified in the Login and Password fields.
Login
Enter a Microsoft SQL Server login that has only the permissions described in this topic.
Password
Enter a strong password for the login specified in Login.
Use a linked server or remote server that you have already defined.
This option requires a linked server or remote server that you have already defined. For more information, see
Linked Servers (Database Engine) and Remote Servers. Ensure that the login used for the linked server or remote
server has a strong password and has only the permissions described in this topic.
See also
Create an Updatable Subscription to a Transactional Publication
View and Modify Replication Security Settings
Initialize Subscriptions
Warehouse
Subscribers must be initialized before they can begin receiving replicated data. An initial dataset is not required, but
the Subscriber must at least have the schema for each replicated object and any metadata tables and procedures
required by replication.
Options
Subscription properties
Select the check box in the Initialize column for each Subscriber that requires an initial data set. If the check box is
cleared, only the replication metadata and procedures will be initialized. For more information about initializing a
subscription without a snapshot, see Initialize a Transactional Subscription Without a Snapshot.
Select Immediately from the drop-down list box in the Initialize When column to have the Merge Agent or
Distribution Agent transfer snapshot files to the Subscriber after this wizard is completed. Select At first
synchronization to have the agent transfer the files the next time it is scheduled to run. The Immediately option
is not available for pull subscriptions to Microsoft SQL Server Express. The Merge Agent and Distribution Agent do
not run on instances of SQL Server Express; therefore the subscription must be initialized through another method.
NOTE
The wizard might prompt for a connection to the Distributor in order to start the appropriate job for the Distribution Agent
or Merge Agent.
See Also
Web Server Information
Warehouse
Web server information is required to use the Web synchronization option for merge replication. For information
about configuring Web synchronization, see Configure Web Synchronization.
Options
Web server address
If you specified a Web server address in the FTP Snapshot andInternet page of the Publication Properties
dialog box, it appears in this text box as a default. Either accept the default or enter a fully qualified Web server
address for the Microsoft Internet Information Services (IIS) server that synchronizes this subscription.
How will each Subscriber connect to the Web server?
Specify the type of authentication used to connect to the Web server. It is recommended to use Basic Authentication
for connections to the IIS server in conjunction with Secure Sockets Layer (SSL). If you select Basic Authentication,
enter the login and password that will be used to connect from the Subscriber to the IIS server.
See Also
Subscription Type
Warehouse
Merge replication offers two subscription types: server and client (referred to in previous versions of Microsoft SQL
Server as global and local, respectively). Subscribers with a server subscription can:
Republish data to other Subscribers.
Serve as alternate synchronization partners.
Resolve conflicts according to a priority you set.
Most Subscribers do not require this functionality and can use a client subscription. Client subscriptions still
allow conflict detection and resolution, but Subscribers are not assigned a priority: the first Subscriber to
submit a change to the Publisher wins any conflicts that might arise from that change.
NOTE
Subscription type cannot be changed after a subscription is created.
Options
For each Subscriber, select Client or Server from the drop-down list box in the Subscription Type column. For
Subscribers with server subscriptions, enter a number between 0 and 99.99 in the Priority for Conflict
Resolution column (the higher the number, the higher the priority for the Subscriber).
See Also
HOST_NAME Values
Warehouse
Merge publications with parameterized filters use the SUSER_SNAME() function and/or the HOST_NAME() function
to filter data. The function is specified in the New Publication Wizard or the Publication Properties dialog box.
By default, the HOST_NAME() function returns the name of the computer connecting to the Publisher. When using
parameterized filters, it is common to override this value by supplying a value on this page of the wizard. The
HOST_NAME() function then returns the value you specify rather than the name of the computer. For more
information, see the "Overriding the HOST_NAME() Value" section of Parameterized Row Filters.
NOTE
If you override HOST_NAME(), all calls to the HOST_NAME() function will return the value you specify. Ensure that other
applications are not depending on HOST_NAME() returning the computer name.
Options
Enter a value for each Subscriber in the HOST_NAME Value column or accept the default, which is the name of the
Subscriber computer.
See Also
HOST_NAME (Transact-SQL)
Warehouse
This section provides information on all pages of the Configure Peer-to-Peer Topology Wizard:
Publication (Peer-to-Peer Replication)
Configure Topology (Peer-to-Peer Replication)
Log Reader Agent Security (Peer-to-Peer Replication)
Distribution Agent Security (Peer-to-Peer Replication)
New Peer Initialization (Peer-to-Peer Replication)
See Also
Administer a Peer-to-Peer Topology (Replication Transact-SQL Programming)
Publication (Peer-to-Peer Replication)
Warehouse
The Publication page displays transactional publications that are enabled for peer-to-peer replication. Publications
are enabled on the Subscription Options page of the Publication Properties dialog box.
Options
Publisher
Displays the server to which you are connected. To connect to a different server, select Find SQL Server Publisher.
Databases and publications
Displays all databases on the server that contain at least one publication that is enabled for peer-to-peer replication.
Select a publication to continue.
See Also
Configure Topology (Peer-to-Peer Replication)
Warehouse
Use the Configure topology page to perform common configuration tasks, such as adding new nodes, deleting
nodes, and adding new connections between existing nodes. The node you selected on the Publication page of
this wizard is displayed on the design surface. To specify configuration options, right-click a node, a connection, or
the design surface.
NOTE
The Configure Peer to Peer Topology Wizard requests topology information when the wizard is closed. If the wizard is closed
and reopened before all nodes respond to the request for information, the wizard might show a partial network.
Options
The Configure topology page contains interface elements and options that are available when you right-click an
element. The following table describes each interface element.
INTERFACE ELEMENT DESCRIPTION
Design surface Displays other interface elements. To add elements, right-click

the design surface.
The original node in the topology. New nodes are initialized by

using a copy of the publication database from the original
node.
A node that is running an instance of SQL Server 2008 or a

later version, for which replication has complete information.
To specify configuration options, right-click the node.
INTERFACE ELEMENT DESCRIPTION
A node for which replication has incomplete information. To

specify configuration options, right-click the node.
Replication has incomplete information because of one of the

following reasons:
-The node is running an instance of SQL Server 2005, which

does not store all the metadata required by the wizard.
-The node is running a later version of SQL Server, but

replication cannot retrieve subscription information from the
node. To troubleshoot this situation:
Make sure that the database at the node is online and that
you can connect to it by using the same credentials as the
Distribution Agents that connect to the node.
Make sure that the Log Reader Agent and all Distribution
Agents that connect to the node are running.
Make sure that the refresh timeout is set high enough to

gather all topology information. To set the time-out, right-
click the design surface, and click Set Refresh Timeout.
Gray line with arrows The connection between two nodes. To add a connection,
right-click one of the nodes that you want to connect. To
remove a connection, right-click the connection.
If the line has a single arrow, replication has incomplete

information for one of the nodes.
Options for the Design Surface

Redraw Graph
Redraw the objects on the design surface without refreshing the topology. Redrawing might provide a better view
of the topology.
Refresh Topology
Query each node in the topology, and display updated information about each node. With many nodes, this process
can take several minutes.
If the wizard requests topology information, and then you close and reopen the wizard before all nodes respond to
the request, this page might not display all nodes in the topology.
Add a New Peer Node
Add an instance of SQL Server to the peer-to-peer topology. Adding an instance as a node creates a publication at
that instance after the wizard completes. After you add the node, right-click it to add a connection between the new
node and an existing node.
To participate in a peer-to-peer topology, the instance must meet the following requirements:
It must already be configured as a Distributor or be associated with a remote Distributor.
It must contain a copy of the database involved in replication. This copy is typically a restored backup of the
original publication database.
Select Node(s) to View
Select which nodes to view on the design surface. This option is useful if the topology has a large number of
nodes. Be aware that you can add connections only between nodes that are visible on the design surface.
Set Refresh Timeout
Specify how long the refresh process can run before the operation times out.
Options for Each Node
Add a New Peer Connection
Add a connection between two nodes. For example, if you add a connection between Node A and Node B,
replication adds two subscriptions: The first enables Node A to receive changes from the publication at Node B, and
the second enables Node B to receive changes from the publication at Node A.
Delete Peer Node
Removes a node from the topology. For example, if you remove Node C, the publication at that node is removed.
Subscriptions between Node A and Node C, and Node B and Node C are also removed. The database at Node C is
not deleted, and publishing and distribution are not disabled.
NOTE
When you configure peer-to-peer replication, you specify an ID for each node. This ID, which must be unique across all nodes
in the topology, is stored in the originator_id column in the MSpeer_originatorid_history system table. If a node is removed
from the topology, the ID is still retained in the history table. The ID is retained to prevent false conflicts from occurring if
there are changes from the removed node that are still being replicated across the topology. If you want to reuse the ID for a
new node, you must first manually delete the ID from the MSpeer_originatorid_history table at all nodes. Before you delete
an ID for a node, execute sp_requestpeerresponse to verify that all changes that originated from that node have been
replicated.
Connect to ALL Displayed Nodes

Adds connections between the selected node and all other nodes. For example, if you selected this option for Node
C in a three node topology, replication adds four subscriptions: two that enable Node A and Node B to receive
changes from the publication at Node C, and two that enable Node C to receive changes from the publications at
Node A and Node B.
Select Node(s) to View
Select which nodes to view on the design surface. This option is useful if the topology has a large number of nodes.
Be aware that you can add connections only between nodes that are visible on the design surface.
Options for the Connection Arrows
Remove Peer Connection
Remove a connection between two nodes. For example, if you remove a connection between Node A and Node B,
replication drops two subscriptions: the one that enables Node A to receive changes from the publication at Node
B, and the one that enables Node B to receive changes from the publication at Node A.
See Also
Log Reader Agent Security (Peer-to-Peer Replication)
Warehouse
The Log Reader Agent Security page allows you to specify the accounts under which the Log Reader Agent at
each peer runs and makes connections. For information on permissions required by agents and best practices for
replication security, see Replication Agent Security Model and Replication Security Best Practices.
NOTE
There is one Log Reader Agent for each database that is published using transactional replication. If the Log Reader Agent for
a database has already been configured (either for a publication in a previous run of this wizard or for another transactional
publication in the same database), you cannot change the credentials it uses in this wizard. If you specify new credentials,
they are ignored. To change credentials, use the Publication Properties dialog box. For more information, see View and
Modify Replication Security Settings.
Options
Click the properties button (...) in the row for each peer to access the Log Reader Agent Security dialog box. Click
Help on the Log Reader Agent Security dialog box that is launched for more information on the permissions
required for accounts used by the agents.
After settings have been entered in the dialog box, connection information for the Subscriber is displayed in the
grid.
Agents for Publisher
The name of each peer server instance.
Peer Database
The database that serves as the publication database and subscription database at each peer.
The context under which the connection to the Distributor is made. The local connection to the Distributor is always
made using the context of the Microsoft Windows account under which the agent runs, so this field will always
display Impersonate '<Domain>\<Login>' or Impersonate '<Computer>\<Login>'.
Connection to Publisher
The context under which the connection to the Publisher is made. The connection to the Publisher can be made
using a Microsoft SQL Server login or using the context of the Windows account under which the agent runs. The
field displays one of the following: Use login '<Login>', Impersonate '<Domain>\<Login>' or Impersonate
'<Computer>\<Login>'. Microsoft recommends that all connections be made using the context of the Windows
account.
See Also
Distribution Agent Security (Peer-to-Peer Replication)
Warehouse
The Distribution Agent Security page allows you to specify the accounts under which the Distribution Agent runs
and makes connections to the computers in a peer-to-peer topology. For information on permissions required by
agents and best practices for replication security, see Replication Agent Security Model and Replication Security
Best Practices.
NOTE
If the Distribution Agent for a subscription has already been configured in a previous run of this wizard, you cannot change
the credentials it uses in this wizard. If you specify new credentials, they are ignored. To change credentials, use the
Subscription Properties dialog box. For more information, see View and Modify Replication Security Settings.
Options
Click the properties button (...) in the row for each Subscriber to access the Distribution Agent Security dialog
box. Click Help on the Distribution Agent Security dialog box that is launched for more information on the
permissions required for accounts used by the agents.
After settings have been entered in one of the dialog boxes, connection information for the Subscriber is displayed
in the grid.
Agent for Subscriber
The name of each peer.
Peer Database
The database at the peer that will serve as both a publication database and subscription database.
The context under which the connection to the Distributor is made. Local connections are always made using the
context of the Windows account under which the agent runs. This wizard creates push subscriptions (the local
connection is the connection to the Distributor), so this field will always display: Impersonate '<Domain>\
<Login>' or Impersonate '<Computer>\<Login>'.
Connection to Subscriber
The context under which the connection to the Subscriber is made. The connection can be made using the context
of the Windows account under which the agent runs or under the context of a SQL Server login. The field displays
one of the following: Use login '<Login>', Impersonate '<Domain>\<Login>' or Impersonate
'<Computer>\<Login>'. Microsoft recommends that all connections be made using the context of the Windows
account.
See Also
New Peer Initialization (Peer-to-Peer Replication)
Warehouse
Use the New Peer Initialization page to specify how peer databases were initialized. (Peers must be initialized
before you complete this wizard.) Peers are initialized manually or by using the initialize with backup
functionality that is provided by transactional replication. (Peer-to-peer transactional replication does not support
initializing peers by using a snapshot.) If different peers have to be initialized using different methods, you must
add the peers separately by running the wizard multiple times.
Options
Specify how the new peer database(s) was initialized
The schema and data for all published objects must be present at each peer. Select one of the following options:
Select the first option if you have manually created the schema for published objects or you have restored a
backup, and no data changes have been made at the first publication database since the backup was taken. If
you created the schema manually, you must ensure that all required data is present at each peer. This option
corresponds to a value of replication support only for the subscription property sync_type.
Select the second option if you have restored a backup, and data changes have been made at the first
publication database since the backup was taken. Replication must now deliver changes from the first
publication database that were not included in the backup. This option corresponds to a value of initialize
with backup for the subscription property sync_type.
When a publication is enabled for peer-to-peer replication, the allow_initialize_from_backup publication
property is set. Replication immediately starts to track changes in the first publication database. Therefore,
these changes can be delivered to a restored database at one or more peers if the initialize with backup
option is selected. Click the Browse button to locate the backup used, and replication will read the log
sequence number (LSN) from the backup. All changes in the first publication database that have a higher
LSN will be delivered to each peer.
This option might not be available if you are creating or adding to a topology that includes SQL Server 2005.
The following table shows whether the option is available when you are adding a node to an existing
topology.
NEW NODE FIRST NODE ADDITIONAL NODES OPTION
SQL Server 2005 SQL Server 2005 SQL Server 2005 Disabled
SQL Server 2005 SQL Server 2008 None Disabled
SQL Server 2008 SQL Server 2008 SQL Server 2005 Disabled
SQL Server 2005 SQL Server 2005 None Enabled
SQL Server 2008 SQL Server 2008 SQL Server 2008 Enabled
NEW NODE FIRST NODE ADDITIONAL NODES OPTION
See Also
Microsoft Replication Conflict Viewer and Interactive
Resolver
Warehouse
This section includes information on the Replication Conflict Viewer for merge replication and transactional
replication, and the Interactive Resolver for merge replication:
Microsoft Replication Conflict Viewer (Merge Replication)
Microsoft Replication Conflict Viewer (Transactional Replication)
Microsoft Replication Interactive Conflict Resolver
Define Filters
See Also
Conflict Detection in Peer-to-Peer Replication
Queued Updating Conflict Detection and Resolution
Microsoft Replication Conflict Viewer (Merge
Replication)
Warehouse
The Replication Conflict Viewer allows you to view any conflicts that have occurred during replication
synchronization. Conflicts occur when the same data is modified at two separate servers, for example, at a
Publisher and Subscriber, or at two different Subscribers. Replication automatically resolves conflicts using the
conflict resolver you selected when the article was created. However, the Replication Conflict Viewer allows you to
choose a different resolution for the conflict when necessary. The following conflicts can occur:
Update conflicts. Update conflicts occur when the same data is changed at two locations. One change wins,
and the other one loses. You have the option to keep the existing data (the data that won), overwrite the
existing data with the data that conflicted with it (the losing data), or merge the winning and losing data and
update the existing data.
Insert conflicts. Insert conflicts occur when a row is inserted at one location that violates some data
consistency rule when merged with changes at other locations. You have the option to keep the existing data
(the data that won), overwrite the existing data with the data that conflicted with it (the losing data), or
merge the winning and losing data and update the existing data.
Delete conflicts. This conflict occurs when the same row is deleted at one location and changed at the other.
When conflicts are resolved during synchronization, the data from the losing row is written to a conflict
table. Whether you accept the original resolution or choose a different resolution for the conflict, the logged
conflict row is deleted from the conflict table. You should periodically review conflicts to help reduce the size
of the conflict tracking tables.
NOTE
Conflicts that involve logical records are not displayed in Conflict Viewer. To view information about these conflicts, use
replication stored procedures. For more information, see View Conflict Information for Merge Publications (Replication
Transact-SQL Programming).
Options
The Replication Conflict Viewer is divided into two sections. The upper section of the dialog box shows the conflict
list for the selected table. When you click an item in the conflict list, the details of the conflict are displayed in the
lower section of the dialog box.
Information describing why the conflict occurred (for example, the same row was updated at both the Publisher
and the Subscriber) is displayed in the lower section of the dialog box. The conflict data in the lower section is
displayed in two corresponding columns (Conflict Winner and Conflict Loser). If the conflict is between updated
and deleted data, there may be no data to show for the deleted side of the conflict. In this case, the Replication
Conflict Viewer displays a message in one of the columns, indicating that the row was deleted at one location and
updated at another. It also indicates the suggested resolution.
Data that cannot be edited in the Replication Conflict Viewer (for example, rowguid data) is displayed read-only
with the box shaded.
Database
Choose a database that includes publications with conflicts.
Publication
Choose a publication that includes tables with conflicts.
Table
Choose a table that includes conflicts.
Define Filter
Click to open the Define Filters dialog box.
Apply or Remove Filter
Click to apply or remove a filter that has been defined in the Define Filters dialog box.
Select All
Click to select all conflicts listed in the grid.
Select None
Click to deselect all conflicts listed in the grid.
Remove
Click to remove selected conflicts from the viewer and their associated metadata from the replication system tables.
Equivalent to clicking the Submit Winner button (without making any changes to the data) for each selected
conflict.
Show all columns
Select to show all columns of the table.
Show first five columns and other columns with conflicting data
Select to display the first five columns and any columns that have conflicts. This is helpful when the table has a
large number of columns, but you want to see only the columns most relevant to resolving the conflict. The first
five columns are always included in this view, as fields that identify a row, such as the primary key or name fields,
are often among the first columns of the table.
Display Column Information ()
Click to view column information: Table Name, Column Name, Data Type, and Column Value. Column Value
is editable unless the value is displayed as read-only.
Submit Winner
Click to keep the row the conflict resolver determined to be the winner. The value of any column that is not
displayed as read-only can be changed prior to clicking this button.
Submit Loser
Click to accept the row the conflict resolver determined to be the loser. The value of any column that is not
displayed as read-only can be changed prior to clicking this button.
Log the details of the conflict
Check this box to log the details of the conflict to a file. To specify a location for the file, point to the View menu
and click Options. Enter a value, or click the browse (...) and navigate to the appropriate file. Click OK to exit the
Options dialog box.
See Also
Microsoft Replication Conflict Viewer (Transactional
Replication)
Warehouse
The Replication Conflict Viewer enables you to view conflicts that have occurred during synchronization for peer-
to-peer transactional replication and transactional replication with queued updating subscriptions. For more
information, see View Data Conflicts for Transactional Publications (SQL Server Management Studio).
NOTE
The Replication Conflict Viewer displays conflicts that occur in merge replication and in transactional replication. For
transactional replication, you can use Replication Conflict Viewer to view conflict data, but you cannot choose a different
resolution for the conflict.
Options
The Replication Conflict Viewer is divided into two sections. The upper section of the dialog box shows the conflict
list for the selected table. When you click an item in the conflict list, the details of the conflict are displayed in the
lower section of the dialog box.
The conflict data in the lower section is displayed in two corresponding columns (Conflict Winner and Conflict
Loser). If the conflict is between updated and deleted data, there may be no data to show for the deleted side of the
conflict. In this case, the Replication Conflict Viewer displays a message in one of the columns, indicating the row
was deleted at one location and updated at another. It also indicates the suggested resolution.
Database
Choose a database that includes publications with conflicts.
Publication
Choose a publication that includes tables with conflicts.
Table
Choose a table that includes conflicts.
Define Filter
Click to open the Define Filters dialog box.
Apply or Remove Filter
Click to apply or remove a filter that has been defined in the Define Filters dialog box.
Select All
Click to select all conflicts listed in the grid.
Select None
Click to deselect all conflicts listed in the grid.
Remove
Click to remove selected conflicts from the viewer and their associated metadata from the replication system tables.
Show all columns
Select to show all columns of the table.
Show first five columns and other columns with conflicting data
Select to display the first five columns and any columns that have conflicts. This is helpful when the table has a
large number of columns, but you want to see only the columns most relevant to resolving the conflict. The first
five columns are always included in this view, as fields that identify a row, such as the primary key or name fields,
are often among the first columns of the table.
Display Column Information ()
Click to view column information: Table Name, Column Name, Data Type, and Column Value.
Log the details of the conflict
Check this box to log the details of the conflict to a file. To specify a location for the file, point to the View menu
and click Options. Enter a value, or click the browse (...) and navigate to the appropriate file. Click OK to exit the
Options dialog box.
See Also
Conflict Detection in Peer-to-Peer Replication
Microsoft Replication Interactive Conflict Resolver
Warehouse
The Interactive Conflict Resolver can be used for merge subscriptions that are synchronized using Windows
Synchronization Manager. It allows you to view, compare, edit, and select the outcome for data conflicts. Replication
also includes the Conflict Viewer, which allows you to view and modify conflict outcomes after they have been
committed. The Interactive Conflict Resolver allows you to select the outcome during synchronization.
NOTE
Conflicts that involve logical records are not displayed in the Interactive Resolver. To view information about these conflicts,
use replication stored procedures. For more information, see View Conflict Information for Merge Publications (Replication
Options
Column name
The name of all columns in the table. One or more columns might have conflicting data. Regardless of which
columns conflict, the entire winning row will overwrite the entire losing row.
Suggested Resolution
The suggested resolution provided by the conflict resolver for the article.
Publisher
The data value at the Publisher.
Subscriber
The data value at the Subscriber.
Accept Suggested, Accept Publisher, and Accept Subscriber
Click to accept the row that will be applied at either the Publisher or the Subscriber, depending on which one lost
the conflict. If the Publisher lost the conflict, all other Subscribers will receive the winning row the next time they
synchronize with the Publisher.
Resolve remaining conflicts automatically
Resolve all remaining conflicts using the suggested resolution provided by the conflict resolver for the article.
Log the details of the conflict for later reference
Logs the details of the conflict in system tables.
See Also
Interactive Conflict Resolution
Synchronize a Subscription Using Windows Synchronization Manager (Windows Synchronization Manager)
Define Filters
Warehouse
The Define Filters dialog box allows you to define filters that you then apply to data conflicts to see a subset of the
conflicts in the grid. To define a filter, choose an operator from the Operator drop-down list box and then enter a
value. For example, to show only those conflicts in which the conflict loser is server ReplTest1, select Equal to
from the Operator drop-down list box and enter ReplTest1 in the first Value column.
Options
Operator
Select an operator for the filter, such as Less than or Equal to.
Value
Enter a value for the filter. Most operators only require a value in the first Value column, but the Between and Not
Between operators require a value in both of the Value columns.
Clear
Click this button to clear all filters that have been previously defined.
See Also
Microsoft Replication Conflict Viewer (Merge Replication)
Microsoft Replication Conflict Viewer (Transactional Replication)
SQL Server Management Studio Replication Dialog
Boxes
Warehouse
This section includes information on a number of replication dialog boxes that are available in Microsoft SQL
Server Management Studio:
Snapshot Agent Security
Log Reader Agent Security
Distribution Agent Security
Merge Agent Security
Queue Reader Agent Security
Agent Profiles (single agent)
Agent Profiles
<AgentProfileName> Properties
New Agent Profile
Validate All Subscriptions
Validate Subscriptions
Validate Subscription
Subscription Validation Options (Transactional Subscriptions)
Subscription Validation Options (Merge Subscriptions)
Reinitialize Subscription(s) - All Subscriptions
Reinitialize Subscription(s) - One Subscription
Generate SQL Script (Replication Objects)
Connect to Server (Oracle), Login
Connect to Server (Oracle), Connection Properties
Snapshot Agent Security
Warehouse
The Snapshot Agent Security dialog box allows you to specify:
The Microsoft Windows account under which the Snapshot Agent runs at the Distributor. The Windows
account is also referred to as the process account, because the agent process runs under this account.
The context under which the Snapshot Agent makes connections to the Microsoft SQL Server Publisher. The
connection can be made by impersonating the Windows account or under the context of a SQL Server
account you specify.
NOTE
The Snapshot Agent makes connections to the Publisher even if the Publisher and Distributor are on the same
computer. The Snapshot Agent also makes connections to the Distributor; these connections are always made by
impersonating the Windows account under which the agent runs.
For Oracle Publishers, specify the context under which the Snapshot Agent connects to the Publisher in the
Publisher Properties dialog box (available from the Distributor Properties dialog box). For more
information, see View and Modify Replication Security Settings.
All accounts must be valid, with the correct password specified for each account. Accounts and passwords
are not validated until an agent runs.
Options
Process account
Enter a Windows account under which the Snapshot Agent runs at the Distributor. The Windows account you
specify must:
At minimum be a member of the db_owner fixed database role in the distribution database.
Have write permissions on the snapshot share.
Password and Confirm password
Enter the password for the Windows account.
Connect to the Publisher
Select whether the Snapshot Agent should make connections to the Publisher by impersonating the account
specified in the Process account text box or by using a SQL Server account. If you select to use a SQL
Server account, enter a SQL Server login and password.
NOTE
It is recommended that you select to impersonate the Windows account rather than using a SQL Server account.
The Windows account or SQL Server account used for the connection must at minimum be a member of the
db_owner fixed database role in the publication database.
See Also
Log Reader Agent Security
Warehouse
The Log Reader Agent Security dialog box allows you to specify:
The Microsoft Windows account under which the Log Reader Agent runs at the Distributor. The Windows
account is also referred to as the process account, because the agent process runs under this account.
The context under which the Log Reader Agent makes connections to the Microsoft SQL Server Publisher.
The connection can be made by impersonating the Windows account or under the context of a SQL Server
account you specify.
NOTE
The Log Reader Agent makes connections to the Publisher even if the Publisher and Distributor are on the same
computer. The Log Reader Agent also makes connections to the Distributor; these connections are always made by
impersonating the Windows account under which the agent runs.
For Oracle Publishers, specify the context under which the Log Reader Agent connects to the Publisher in the
Publisher Properties dialog box (available from the Distributor Properties dialog box). For more
information, see View and Modify Replication Security Settings.
Options
Process account
Enter a Windows account under which the Log Reader Agent runs at the Distributor. The Windows account you
specify must at minimum be a member of the db_owner fixed database role in the distribution database.
Connect to the Publisher
Select whether the Log Reader Agent should make connections to the Publisher by impersonating the account
specified in the Process account text box or by using a SQL Server account. If you select to use a SQL Server
account, enter a SQL Server login and password.
NOTE
Microsoft recommends that you select to impersonate the Windows account rather than using a SQL Server account.
The Windows account or SQL Server account used for the connection must at minimum be a member of the
db_owner fixed database role in the publication database.
See Also
Distribution Agent Security
Warehouse
The Distribution Agent Security dialog box allows you to specify the Windows account under which the
Distribution Agent runs. The Distribution Agent runs at the Distributor for push subscriptions and at the Subscriber
for pull subscriptions. The Microsoft Windows account is also referred to as the process account, because the agent
process runs under this account. Additional options available in the dialog box depend on how you access it:
If the dialog box is accessed from the New Subscription Wizard, it also allows you to specify the context
under which the Distribution Agent makes connections to the Subscriber (for push subscriptions) or the
Distributor (for pull subscriptions). The connection can be made by impersonating the Windows account or
under the context of a Microsoft SQL Server account you specify.
If the dialog box is accessed from the Subscription Properties dialog box, specify the context under which
the Distribution Agent makes connections by clicking the properties button (...) in the Subscriber
Connection or Distributor Connection row of that dialog box. For more information about accessing the
Subscription Properties dialog box, see View and Modify Push Subscription Properties and how to: View
and Modify Pull Subscription Properties.
Options
Process Account
Enter a Windows account under which the Distribution Agent runs:
For push subscriptions, the account must:
Be a member of the publication access list (PAL).
Have read permissions on the snapshot share.
Have read permissions on the install directory of the OLE DB provider for the Subscriber if the
subscription is for a non- SQL Server Subscriber.
For pull subscriptions, the account must at minimum be a member of the db_owner fixed database role in
Additional permissions are required if the process account is impersonated when connections are made. See
the Connect to the Distributor and Connect to the Subscriber sections below.
Process Account cannot be specified for pull subscriptions to Microsoft SQL Server Express, because the
Distribution Agent does not run on instances of SQL Server Express.
Password and Confirm Password
Connect to the Distributor
For push subscriptions, connections to the Distributor are always made by impersonating the account
specified in the Process account text box.
For pull subscriptions, select whether the Distribution Agent should make connections to the Distributor by
impersonating the account specified in the Process account text box or by using a SQL Server account. If
you select to use a SQL Server account, enter a SQL Server login and password.
NOTE
The Windows account or SQL Server account used for the connection must:
Be a member of the PAL.
Connect to the Subscriber
For pull subscriptions, connections to the Subscriber are always made by impersonating the account
For push subscriptions, the options are different for SQL Server Subscribers and non- SQL Server
Subscribers:
For SQL Server Subscribers: select whether the Distribution Agent should make connections to the
Subscriber by impersonating the account specified in the Process account text box or by using a SQL
Server account. If you select to use a SQL Server account, enter a SQL Server login and password.
NOTE
The Windows account or SQL Server account used for the connection to the Subscriber must at minimum be
a member of the db_owner fixed database role in the subscription database.
For non- SQL Server Subscribers, specify the database login at the Subscriber that should be used when the
Distribution Agent connects to the Subscriber. The login should have sufficient permissions to create objects
in the subscription database. For more information about configuring non- SQL Server Subscribers, see
Create a Subscription for a Non-SQL Server Subscriber.
Additional connection options
Non- SQL Server Subscribers only. Specify any connection options for the Subscriber in the form of a
connection string (Oracle does not require additional options). Each option should be separated by a semi-
colon. The following is an example of an IBM DB2 connection string (line breaks are for readability):
Provider=DB2OLEDB;Initial Catalog=MY_SUBSCRIBER_DB;Network Transport Library=TCP;Host CCSID=1252;

PC Code Page=1252;Network Address=MY_SUBSCRIBER;Network Port=50000;Package Collection=MY_PKGCOL;
Default Schema=MY_SCHEMA;Process Binary as Character=False;Units of Work=RUW;DBMS Platform=DB2/NT;
Persist Security Info=False;Connection Pooling=True;
Most of the options in the string are specific to the DB2 server you are configuring, but the Process Binary as
Character option should always be set to False. A value is required for the Initial Catalog option to identify the
subscription database. For more information, see IBM DB2 Subscribers.
See Also
Merge Agent Security
Warehouse
The Merge Agent Security dialog box allows you to specify the Microsoft Windows account under which the
Merge Agent runs. The Merge Agent runs at the Distributor for push subscriptions and at the Subscriber for pull
subscriptions. The Windows account is also referred to as the process account, because the agent process runs
under this account. Additional options available in the dialog box depend on how you access it:
If the dialog box is accessed from the New Subscription Wizard, it also allows you to specify the context
under which the Merge Agent makes connections to the Subscriber (for push subscriptions) or the Publisher
and Distributor (for pull subscriptions). The connection can be made using the Windows account or under
the context of a Microsoft SQL Server account you specify.
If the dialog box is accessed from the Subscription Properties dialog box, specify the context under which
the Merge Agent makes connections by clicking the properties button (...) in the Subscriber Connection or
Publisher Connection row of that dialog box. For more information about accessing the Subscription
Properties dialog box, see View and Modify Push Subscription Properties and how to: View and Modify Pull
Subscription Properties.
Options
Process Account
Enter a Windows account under which the Merge Agent runs.
For push subscriptions, the account must:
Be a login associated with a user in the publication database.
For pull subscriptions, the account must at minimum be a member of the db_owner fixed database role in
Additional permissions are required if the process account is impersonated when connections are made. See
the Connect to the Publisher and Distributor and Connect to the Subscriber sections below.
Process Account cannot be specified for pull subscriptions to Microsoft SQL Server Express, because the
Merge Agent does not run on instances of SQL Server Express.
Password and Confirm Password
Connect to the Publisher and Distributor
For push subscriptions, connections to the Publisher and Distributor are always made by impersonating the
account specified in the Process account text box.
For pull subscriptions, select whether the Merge Agent should make connections to the Publisher and
Distributor by impersonating the account specified in the Process account text box or by using a SQL
NOTE
Microsoft recommends that you select to impersonate the Windows account rather than using a SQL Server account.
The Windows account or SQL Server account used for the connection must:
Be a login associated with a user in the publication database.
Be a login associated with a user in the distribution database (the user can be the Guest user).
Connect to the Subscriber
For pull subscriptions, connections to the Subscriber are always made by impersonating the account
For push subscriptions, select whether the Merge Agent should make connections to the Publisher and
Distributor by impersonating the account specified in the Process account text box or by using a SQL
NOTE
The Windows account or SQL Server account used for the connection to the Subscriber must at minimum be a
member of the db_owner fixed database role in the subscription database.
See Also
Queue Reader Agent Security
Warehouse
The Queue Reader Agent Security dialog box allows you to specify the Microsoft Windows account under which
the Queue Reader Agent runs and makes local connections to the Distributor. The agent connects to the Publisher
using the account specified in the Publisher Properties dialog box (available from the Distributor Properties
dialog box); the agent connects to the Subscriber using the same context as the Distribution Agent for the
subscription. For more information, see View and Modify Replication Security Settings.
The account must be valid with the correct password specified. Accounts and passwords are not validated until an
agent runs.
Options
Process account
Enter a Windows account under which the Queue Reader Agent runs at the Distributor. The Windows account you
specify must at minimum be a member of the db_owner fixed database role in the distribution database.
See Also
Agent Profiles (single agent)
Warehouse
Use the Agent Profiles dialog box to manage profiles for an agent. Agent profiles provide a convenient way to
manage the runtime parameters for each agent. Each agent has a default profile, and some agents have additional
predefined profiles. For example, the Merge Agent has a "slow link" profile designed for low bandwidth
connections. Predefined profiles are sufficient for most applications, but you can also create user-defined profiles,
allowing you to customize agent behavior.
Options
Default for New
Select the profile that will be used when jobs are created for an agent of a given type. For example, if you create a
number of subscriptions to a merge publication, the Merge Agent job for each subscription will use the profile
selected. If you want to change the profile for existing jobs, select a profile, and then click Change Existing Agents.
Name
The name of the profile.
Type
The type of profile: User (user-defined) or System (predefined).
Properties (...)
Click to view the values used for each parameter in the agent profile.
New
Click to create a new profile.
Delete
Select a user-defined profile, and then click Delete to delete that profile. Predefined profiles cannot be deleted.
Change Existing Agents
Select a profile, and then click Change Existing Agents to specify that all existing jobs for an agent of a given type
should use the selected profile. For example, if you have created a number of subscriptions to a merge publication,
and you want to change the profile to specify that the Merge Agent job for each of these subscriptions should use
the Slow link agent profile, select that profile, and then click Change Existing Agents.
See Also
Work with Replication Agent Profiles
Replication Agent Profiles
Agent Profiles
Warehouse
Use the Agent Profiles dialog box to manage agent profiles. Agent profiles provide a convenient way to manage
the runtime parameters for each agent. Each agent has a default profile, and some agents have additional
predefined profiles. For example, the Merge Agent has a "slow link" profile designed for low bandwidth
connections. Predefined profiles are sufficient for most applications, but you can also create user-defined profiles,
allowing you to customize agent behavior.
Options
Select a page
Select an agent in the left pane, and the profiles for the agent are displayed in the right pane.
Default for New
Select the profile that will be used when jobs are created for an agent of a given type. For example, if you create a
number of subscriptions to a merge publication, the Merge Agent job for each subscription will use the profile
selected. If you want to change the profile for existing jobs, select a profile, and then click Change Existing Agents.
Name
Type
The type of profile: User (user-defined) or System (predefined).
Properties (...)
Click to view the values used for each parameter in the agent profile.
New
Click to create a new profile.
Delete
Select a user-defined profile, and then click Delete to delete that profile. Predefined profiles cannot be deleted.
Change Existing Agents
Select a profile, and then click Change Existing Agents to specify that all existing jobs for an agent of a given type
should use the selected profile. For example, if you have created a number of subscriptions to a merge publication,
and you want to change the profile to specify that the Merge Agent job for each of these subscriptions should use
the Slow link agent profile, select that profile, and then click Change Existing Agents.
See Also
<AgentProfileName> Properties
Warehouse
Use the Agent Profiles Properties dialog box to view the values specified for each agent parameter in a profile
and to modify the values for user-defined profiles.
Options
Name
Description
A description of the profile.
Parameter
The agent parameters included in the profile. Profiles do not necessarily specify a value for each parameter. To see
all parameters that are valid for a given agent, clear the Show only parameters used in this profile check box.
For descriptions of each parameter, see:
Default Value
The default value for each agent parameter.
Value
The value specified for the parameter in the profile. This field is editable for user-defined profiles.
Show only parameters used in this profile
Clear to show all valid parameters for a given agent.
See Also
New Agent Profile
Warehouse
Use the New Agent Profile dialog box to create a new profile. New profiles are always based on existing profiles,
but they can be modified to meet application requirements. After a profile has been created, it can be applied to
existing and future agent jobs in the Agent Profiles dialog box. Agent parameter values can be edited in the
<AgentProfileName> Properties dialog box.
Options
Name
Enter a name for the profile.
Description
Enter a description for the profile.
Parameter
The agent parameters included in the profile. The profile on which the new profile is based does not necessarily
specify a value for each parameter. To see all parameters that are valid for a given agent, clear the Show only
parameters used in this profile check box. For descriptions of each parameter, see:
Default Value
The default value for each agent parameter.
Value
The value specified for the parameter in the profile on which the new profile is based. Edit this field for any
parameter values you want to change.
Show only parameters used in this profile
Clear to show all valid parameters for a given agent.
See Also
Validate All Subscriptions
Warehouse
Use the Validate All Subscriptions dialog box to specify that all subscriptions to a merge publication should be
validated the next time the Merge Agent for each subscription runs. The results of validation are displayed in
Replication Monitor. For more information, see Validate Data at the Subscriber.
It is also possible to validate a single subscription by right-clicking a subscription in SQL Server Management
Studio and clicking Validate Subscription.
Options
Verify the row counts only
Select to validate whether the table at the Subscriber has the same number of rows as the table at the Publisher.
This method does not validate that the content of the rows matches. Row count validation provides a lightweight
approach to validation that can make you aware of issues with your data.
Verify the row counts and compare checksums to verify the row data
In addition to taking a count of rows at the Publisher and Subscriber, a checksum of all the data is calculated using
the binary checksum algorithm. If the row count fails, the checksum is not performed. This option is not valid for
SQL Server Compact.
See Also
Validate Subscriptions
Warehouse
Use the Validate Subscriptions dialog box to specify that subscriptions to a transactional publication should be
validated the next time the Distribution Agent for each subscription runs. The results of validation are displayed in
Replication Monitor. For more information, see Validate Data at the Subscriber.
Options
Validate all SQL Server subscriptions
Select to validate data for all SQL Server subscriptions to this publication.
Validate the following subscriptions
Select if you do not want to validate all subscriptions. Select from the list the subscriptions you want to validate.
Validation Options
Click to access the Subscription Validation Options dialog box, which allows you to specify whether to use row
count validation or binary checksum validation.
See Also
Validate Subscription
Warehouse
Use the Validate Subscription dialog box to specify that a subscription to a merge publication should be validated
the next time the Merge Agent for the subscription runs. The results of validation are displayed in Replication
Monitor. For more information, see Validate Data at the Subscriber.
It is also possible to validate all subscriptions to a merge publication by right-clicking a publication in Microsoft
SQL Server Management Studio and clicking Validate All Subscriptions.
Options
Date of the last attempted validation
The date of the last Merge Agent session that included subscription validation, whether or not that validation was
successful.
Date of the last successful validation
The date of the last Merge Agent session that included a successful subscription validation.
Validate this subscription
Select to validate the subscription.
Options
Click to access the Subscription Validation Options dialog box, which allows you to specify whether to use row
count validation or binary checksum validation.
See Also
Subscription Validation Options (Transactional
Subscriptions)
Warehouse
Use the Subscription Validation Options dialog box to specify whether validation should use a row count only,
or a row count and a binary checksum.
Options
Verify that the Subscriber has the same number of rows of replicated data as the Publisher
Select the type of row count validation to perform. For Oracle publications, the only available option is Compute
an actual row count by querying the tables directly.
Compare checksums to verify row data
the binary checksum algorithm. If the row count fails, the checksum is not performed.
Stop the Distribution Agent after the validation has completed
By default, the Distribution Agent runs continuously. Select this option to stop the agent after validation is
performed. This allows you to check whether validation was successful before continuing to replicate data to the
Subscriber.
See Also
Subscription Validation Options (Merge Subscriptions)
Warehouse
Use the Subscription Validation Options dialog box to specify whether validation should use a row count only or
a row count and a binary checksum.
Options
Verify the row counts only
Select to validate whether the table at the Subscriber has the same number of rows as the table at the Publisher.
This method does not validate that the content of the rows matches. Row count validation provides a lightweight
approach to validation that can make you aware of issues with your data.
Verify the row counts and compare checksums to verify the row data
the binary checksum algorithm. If the row count fails, the checksum is not performed. This option is not valid for
Microsoft SQL Server Compact.
See Also
Reinitialize Subscription(s) - All Subscriptions
Warehouse
The Reinitialize Subscription(s) dialog box allows you to mark all subscriptions to a publication for
reinitialization. Reinitialization involves applying a snapshot to each Subscriber; it is performed by the Distribution
Agent for subscriptions to transactional publications and by the Merge Agent for subscriptions to merge
publications.
Options
Select to apply the current snapshot to each Subscriber the next time the Distribution Agent or Merge Agent runs
for the subscription. If there is no valid snapshot available, this option cannot be selected.
Use a new snapshot
Select to reinitialize all subscriptions with a new snapshot. The snapshot can be applied to each Subscriber only
after it has been generated by the Snapshot Agent. If the Snapshot Agent is set to run on a schedule, subscriptions
will not be reinitialized until after the next scheduled Snapshot Agent run.
Select Generate the new snapshot now to start the Snapshot Agent immediately.
Merge replication only. Select to upload any pending changes from the subscription databases before the data at
the Subscribers is overwritten with a snapshot.
Mark for Reinitialization
Click to mark each subscription for reinitialization. After a valid snapshot is available, the next time the Distribution
Agent or Merge Agent runs for the subscription, the snapshot is applied at the Subscriber.
See Also
Reinitialize Subscription(s) - One Subscription
Warehouse
The Reinitialize Subscription(s) dialog box allows you to mark a subscription for reinitialization. Reinitialization
involves applying a snapshot to the Subscriber; it is performed by the Distribution Agent for subscriptions to
transactional publications and by the Merge Agent for subscriptions to merge publications.
Options
Select to apply the current snapshot to the Subscriber the next time the Distribution Agent or Merge Agent runs. If
there is no valid snapshot available, this option cannot be selected.
Use a new snapshot
Select to reinitialize the subscription with a new snapshot. The snapshot can be applied to the Subscriber only after
it has been generated by the Snapshot Agent. If the Snapshot Agent is set to run on a schedule, the subscription will
not be reinitialized until after the next scheduled Snapshot Agent run.
Select Generate the new snapshot now to start the Snapshot Agent immediately.
Merge replication only. Select to upload any pending changes from the subscription database before the data at the
Subscriber is overwritten with a snapshot.
Mark for Reinitialization
Click to mark the subscription for reinitialization. After a valid snapshot is available, the next time the Distribution
Agent or Merge Agent runs for the subscription, the snapshot is applied at the Subscriber.
See Also
Generate SQL Script (Replication Objects)
Warehouse
A replication script contains the Transact-SQL system stored procedures necessary to implement the replication
components scripted, such as a publication or subscription. All replication components in a topology should be
scripted as part of a disaster recovery plan, and scripts can also be used to automate repetitive tasks. Replication
offers two dialog boxes for scripting replication objects:
Generate SQL Script, which is available from the context menu of the Replication folder and all subfolders
in Microsoft SQL Server Management Studio. This dialog box allows you to script all replication objects on
an instance of Microsoft SQL Server.
Generate SQL Script <ObjectName>, which is available from the context menu for publications and
subscriptions. This dialog box allows you to script individual objects.
These dialog boxes script objects on a single instance of SQL Server; they do not connect to other instances
to script related objects.
Generate SQL Script Options

Distributor properties
Select to script stored procedures to: enable or disable the Distributor; add or drop Publishers associated with the
Distributor; and create or drop the distribution database.
Publications in the following data sources
Select to script stored procedures to: enable or disable publishing; and create or drop publications, articles, push
subscriptions, and replication jobs.
Subscriptions in the following data sources
Select to script stored procedures to create or drop pull subscriptions and replication jobs.
To create or enable the components and To drop or disable the components
Specify whether the script should include commands for creating or dropping a replication object. Microsoft
recommends that you use the dialog box to create a set of scripts for enabling and disabling components.
Replication jobs
Select to script replication jobs in addition to stored procedure calls. This option is available only when scripting
from a Distributor.
Replication stored procedures create the necessary jobs when they are executed, so it is not required to select this
option. However, it can be useful to have a record of the jobs created in case an individual job must be recreated.
Generate SQL Script <ObjectName> Options

To create or enable the components and To drop or disable the components
Specify whether the script should include commands for creating or dropping a replication object. Microsoft
recommends that you use the dialog box, creating a set of scripts for enabling and disabling components.
Replication jobs
This option is available only from the Generate SQL Script dialog box.
See Also
Connect to Server (Oracle), Login
Warehouse
Use the Login tab of the Connect to Server dialog box to specify the account under which connections are made
from the Microsoft SQL Server Distributor to the Oracle Publisher. You must use the same account as the one
specified for the replication administrative user schema during configuration of the Publisher. For more
information, see Configure an Oracle Publisher.
Options
Server instance
The Transparent Network Substrate (TNS) name of the Oracle Publisher, which is specified during configuration of
the Oracle client software installed on the Distributor.
Authentication
Select Oracle Standard Authentication (recommended) or Windows Authentication. If you select Windows
Authentication:
The Oracle server must be configured to allow connections using Windows credentials. For more
information, see the Oracle documentation.
You must be currently logged in with the same Microsoft Windows account you specified for the replication
administrative user schema.
Login and Password
If you selected Oracle Standard Authentication for the Authentication option, specify the login and
password to use, which must be the same as those specified for the replication administrative user schema.
See Also
Glossary of Terms for Oracle Publishing
Connect to Server (Oracle), Connection Properties
Warehouse
Use the Connection Properties tab of the Connect to Server dialog box to specify a publishing option of
Gateway or Complete. After a Publisher is identified, this option cannot be changed without dropping and
reconfiguring the Publisher. For more information, see Configure an Oracle Publisher.
Options
Publisher type
Select Gateway or Complete. The Complete option is designed to provide snapshot and transactional
publications with the complete set of supported features for Oracle publishing. The Gateway option provides
specific design optimizations to improve performance for cases where replication serves as a gateway between
systems. The Gateway option cannot be used if you plan to publish the same table in multiple transactional
publications. A table can appear in at most one transactional publication and any number of snapshot publications
if you select Gateway.
Timeouts
Specify how long the Microsoft SQL Server Distributor should attempt to connect to the Oracle Publisher before a
timeout error occurs.
See Also
Glossary of Terms for Oracle Publishing
Performance Tuning for Oracle Publishers
Data Warehouse
This section of the documentation contains cause and resolution information for a number of errors related
to replication.
ERROR MESSAGE
MSSQL_ENG002601 Cannot insert duplicate key row in object '%.*ls' with

unique index '%.*ls'.
MSSQL_ENG002627 Violation of %ls constraint '%.*ls'. Cannot insert duplicate

key in object '%.*ls'.
MSSQL_ENG003165 Database '%ls' was restored, however an error was

encountered while replication was being restored/removed.
The database has been left offline. See the topic
MSSQL_ENG003165 in SQL Server Books Online.
MSSQL_ENG003724 Cannot %S_MSG the %S_MSG '%.*ls' because it is being

used for replication.
MSSQL_ENG004929 Cannot alter the %S_MSG '%.*ls' because it is being

published for replication.
MSSQL_ENG007395. See Troubleshooting Oracle Unable to start a nested transaction for OLE DB provider
Publishers. "%ls" for linked server "%ls". A nested transaction was
required because the XACT_ABORT option was set to OFF.
MSSQL_ENG014005 Could not drop publication. A subscription exists to it.
MSSQL_ENG014010 The server '%s' is not defined as a subscription server.
MSSQL_ENG014114 '%s' is not configured as a Distributor.
MSSQL_ENG014117 '%s' is not configured as a distribution database.
MSSQL_ENG014120 Could not drop the distribution database '%s'. This

distributor database is associated with a Publisher.
MSSQL_ENG014121 Could not drop the Distributor '%s'. This Distributor has
associated distribution databases.
MSSQL_ENG014144 Cannot drop Subscriber '%s'. There are subscriptions for it

in the publication database '%s'.
MSSQL_ENG014150 Replication-%s: agent %s succeeded. %s
MSSQL_ENG014151 Replication-%s: agent %s failed. %s

ERROR MESSAGE
MSSQL_ENG014152 Replication-%s: agent %s scheduled for retry. %s
MSSQL_ENG014157 The subscription created by Subscriber '%s' to publication

'%s' has expired and has been dropped.
MSSQL_ENG014160 The threshold [%s:%s] for the publication [%s] has been set.
One or more subscriptions to this publication have expired.
Make sure that the logreader and distribution agents are
running and can match the latency requirement.
Please make sure that the merge agent is running and can
match the expected requirement.
MSSQL_ENG018456 Login failed for user '%.*ls'.%.*ls
MSSQL_ENG018752 Only one Log Reader Agent or log-related procedure

(sp_repldone, sp_replcmds, and sp_replshowcmds) can
connect to a database at a time. If you executed a log-
related procedure, drop the connection over which the
procedure was executed or execute sp_replflush over that
connection before starting the Log Reader Agent or
executing another log-related procedure.
MSSQL_ENG020554 The replication agent has not logged a progress message

in %ld minutes. This might indicate an unresponsive agent
or high system activity. Verify that records are being
replicated to the destination and that connections to the
Subscriber, Publisher, and Distributor are still active.
MSSQL_ENG020557 Agent shutdown. For more information, see the SQL Server
Agent job history for job '%s'.
MSSQL_ENG020572 Subscriber '%s' subscription to article '%s' in publication

'%s' has been reinitialized after a validation failure.

'%s' failed data validation.

'%s' passed data validation.
ERROR MESSAGE
MSSQL_ENG020596 Only '%s' or members of db_owner can drop the

anonymous agent.
MSSQL_ENG020598 The row was not found at the Subscriber when applying
the replicated command.
MSSQL_ENG021075 The initial snapshot for publication '%s' is not yet available.
MSSQL_ENG021076 The initial snapshot for article '%s' is not yet available.
MSSQL_ENG021286 Conflict table '%s' does not exist.
MSSQL_ENG021330 Failed to create a sub-directory under the replication

working directory.(%ls)
MSSQL_ENG021331 Failed to copy user script file to the Distributor.(%ls)
MSSQL_ENG021385 Snapshot failed to process publication '%s'. Possibly due to

active schema change activity or new articles being added.
MSSQL_ENG021617. See Troubleshooting Oracle Unable to run SQL*PLUS. Make certain that a current
Publishers. version of the Oracle client code is installed at the
distributor.
MSSQL_ENG021620. See Troubleshooting Oracle The version of SQL*PLUS that is accessible through the
Publishers. system Path variable is not current enough to support
Oracle publishing. Make certain that a current version of
the Oracle client code is installed at the distributor.
MSSQL_ENG021624. See Troubleshooting Oracle Unable to locate the registered Oracle OLEDB provider,
Publishers. OraOLEDB.Oracle, at distributor '%s'. Make certain that a
current version of the Oracle OLEDB provider is installed
and registered at the distributor.
MSSQL_ENG021626. See Troubleshooting Oracle Unable to connect to Oracle database server '%s' using the
Publishers. Oracle OLEDB provider OraOLEDB.Oracle.
MSSQL_ENG021627. See Troubleshooting Oracle Unable to connect to Oracle database server '%s' using the
Publishers. Microsoft OLEDB provider MSDAORA.
MSSQL_ENG021628. See Troubleshooting Oracle Unable to update the registry of distributor '%s' to allow
Publishers. Oracle OLEDB provider OraOLEDB.Oracle to run in process
with SQL Server. Make certain that current login is
authorized to modify SQL Server owned registry keys.
MSSQL_ENG021629. See Troubleshooting Oracle The CLSID registry key indicating that the Oracle OLEDB
Publishers. Provider for Oracle, OraOLEDB.Oracle, has been registered
is not present at the distributor. Make certain that the
Oracle OLEDB provider is installed and registered at the
distributor.
MSSQL_ENG021642. See Troubleshooting Oracle Heterogeneous publishers require a linked server. A linked
Publishers. server named '%s' already exists. Please remove linked
server or choose a different publisher name.
ERROR MESSAGE
MSSQL_ENG021663. See Troubleshooting Oracle No valid primary key found for source table [%s].[%s].
Publishers.
MSSQL_ENG021684. See Troubleshooting Oracle The permissions associated with the administrator login for
Publishers. Oracle publisher '%s' are not sufficient.
MSSQL_ENG021797 '%s' must be a valid Windows Login in the form:

'MACHINE\Login' or 'DOMAIN\Login'. Please see the
documentation for '%s'.
MSSQL_ENG021798 The '%s' agent job must be added via '%s' before
continuing. Please see the documentation for '%s'.
MSSQL_REPL020011 The process could not execute '%1' on '%2'.
MSSQL_REPL027056 The merge process was unable to change generation

history at the '%1'. When troubleshooting, restart the
synchronization with verbose history logging and specify
an output file to which to write.
MSSQL_REPL027183 The merge process failed to enumerate changes in articles

with parameterized row filters. If this failure continues,
increase the query timeout for this process, reduce the
retention period for the publication, and improve indexes
on published tables.
MSSQL_ENG002601
Warehouse
Message Details
Product Name SQL Server
Event ID 2601
Event Source MSSQLSERVER
Component SQL Server Database Engine
Symbolic Name N/A
Message Text Cannot insert duplicate key row in object '%.*ls' with unique
index '%.*ls'.
Explanation
This is a general error that can be raised regardless of whether a database is replicated. In replicated databases, the
error is typically raised because primary keys have not been managed appropriately across the topology. In a
distributed environment it is essential to ensure that the same value is not inserted into a primary key column or
any other unique column at more than one node. Possible causes include the following:
Inserts and updates to a row are occurring at more than one node. Merge replication and updatable
subscriptions for transactional replication both provide conflict detection and resolution, but it is still
preferable to insert or update a given row at only one node. Peer-to-peer transactional does not provide
conflict detection and resolution; it requires that inserts and updates be partitioned.
A row was inserted at a Subscriber that should be read-only. Subscribers to snapshot publications should be
treated as read-only, as should Subscribers to transactional publications unless updatable subscriptions or
peer-to-peer transactional replication is used.
A table with an identity column is being used, but the column is not managed appropriately.
In merge replication, this error can also occur during an insert into the system table MSmerge_contents;
the error raised is similar to: Cannot insert duplicate key row in object 'MSmerge_contents' with unique
index 'ucl1SycContents.'
User Action
The action required depends on the reason the error was raised:
Inserts and updates to a row are occurring at more than one node.
Regardless of the type of replication used, we recommend that you partition inserts and updates whenever
possible, because this reduces the processing required for conflict detection and resolution. For peer-to-peer
transactional replication, partitioning inserts and updates is required. For more information, see Peer-to-
Peer Transactional Replication.
A row was inserted at a Subscriber that should be read-only.
Do not insert or update rows at the Subscriber unless you are using merge replication, transactional
replication with updatable subscriptions, or peer-to-peer transactional replication.
For merge replication and transactional replication with updatable subscriptions, identity columns should be
managed automatically by replication. For peer-to-peer transactional replication, they must be managed
manually. For more information, see Replicate Identity Columns.
The error occurs during an insert into the system table MSmerge_contents.
This error can occur because of an incorrect value for the join filter property join_unique_key. This
property should be set to TRUE only if the joined column in the parent table is unique. If the property is set
to TRUE, but the column is not unique, this error is raised. For more information on setting this property, see
Define and Modify a Join Filter Between Merge Articles.
See Also
MSSQL_ENG002627
Warehouse
Message Details
Event ID 2627
Symbolic Name N/A
Message Text Violation of %ls constraint '%.*ls'. Cannot insert duplicate key
in object '%.*ls'.
Explanation
This is a general error that can be raised regardless of whether a database is replicated. In replicated databases, the
error is typically raised because primary keys have not been managed appropriately across the topology. In a
distributed environment it is essential to ensure that the same value is not inserted into a primary key column or
any other unique column at more than one node. Possible causes include the following:
Inserts and updates to a row are occurring at more than one node. Merge replication and updatable
subscriptions for transactional replication both provide conflict detection and resolution, but it is still
preferable to insert or update a given row at only one node. Peer-to-peer transactional does not provide
conflict detection and resolution; it requires that inserts and updates be partitioned.
A row was inserted at a Subscriber that should be read-only. Subscribers to snapshot publications should be
treated as read-only, as should Subscribers to transactional publications unless updatable subscriptions or
peer-to-peer transactional replication is used.
User Action
The action required depends on the reason the error was raised:
Inserts and updates to a row are occurring at more than one node.
Regardless of the type of replication used, we recommend that you partition inserts and updates whenever
possible, because this reduces the processing required for conflict detection and resolution. For peer-to-peer
transactional replication, partitioning inserts and updates is required. For more information, see Peer-to-
Peer Transactional Replication.
A row was inserted at a Subscriber that should be read-only.
Do not insert or update rows at the Subscriber unless you are using merge replication, transactional
replication with updatable subscriptions, or peer-to-peer transactional replication.
For merge replication and transactional replication with updatable subscriptions, identity columns should be
managed automatically by replication. For peer-to-peer transactional replication, they must be managed
manually. For more information, see Replicate Identity Columns.
See Also
Merge Replication
MSSQL_ENG003165
Warehouse
Message Details
Event ID 3165
Symbolic Name
Message Text Database '%ls' was restored; however, an error was

encountered while replication was being restored/removed.
The database has been left offline. See the topic
MSSQL_ENG003165 in SQL Server Books Online.
Explanation
This error is raised if a problem occurs restoring a backup of a replicated database:
If the backup is being restored to the same database and server on which it was taken, the error indicates
that replication settings could not be restored properly.
If the backup is being restored to a different database or server, the error indicates that replication settings
could not be removed properly (by default, replication settings are removed if the database or server is
different).
The error is probably the result of a mismatch between the state of the restored database and one or more
system databases that contain replication metadata: msdb, master, or the distribution database.
User Action
To resolve this issue:
1. Execute ALTER DATABASE to bring the database online; for example:
ALTER DATABASE AdventureWorks SET ONLINE . For more information, see ALTER DATABASE (Transact-SQL). If
you want to preserve replication settings, go to step 2. If not, go to step 3.
2. Execute sp_restoredbreplication (Transact-SQL). If this stored procedure executes successfully, the restore is
complete. If it does not execute successfully, go to step 3.
3. Execute sp_removedbreplication (Transact-SQL) to remove all replication settings.
Reconfigure replication if necessary. If you have scripted the replication topology as recommended, use
scripts to reconfigure the topology.
See Also
Back Up and Restore of SQL Server Databases
MSSQL_ENG003724
Warehouse
Message Details
Event ID 3724
Symbolic Name
Message Text Cannot %S_MSG the %S_MSG '%.*ls' because it is being used
for replication.
Explanation
When objects in a database are replicated, they are marked as replicated in the system table sysarticles (for
snapshot and transactional publications) or sysmergearticles (for merge publications). If you attempt drop a
replicated object, this error is raised.
User Action
Ensure the database object is not replicated before attempting to drop it. For example:
If the error occurs in the publication database, drop the article from the publication before dropping the
object. For more information, see Add Articles to and Drop Articles from Existing Publications.
If the error occurs in the subscription database, drop the subscription before dropping the object. For more
information, see Subscribe to Publications. For subscriptions to transactional publications, it is possible to
drop the subscription to an individual article rather than the entire publication. For more information, see
sp_dropsubscription (Transact-SQL).
If this error occurs in a database that is not replicated, execute sp_removedbreplication (Transact-SQL) to
ensure objects in the database are not marked as replicated.
See Also
MSSQL_ENG004929
Warehouse
Message Details
Event ID 4929
Symbolic Name
Message Text Cannot alter the %S_MSG '%.*ls' because it is being published
for replication.
Explanation
This error typically occurs if you attempt to drop the primary key constraint on a table that is published for
transactional replication. Transactional replication requires a primary key for each published table; therefore the
constraint cannot be dropped.
User Action
To drop the constraint, first drop the article associated with the table. For more information, see Add Articles to and
Drop Articles from Existing Publications. If this error occurs in a database that is not replicated, execute
sp_removedbreplication (Transact-SQL) to ensure objects in the database are not marked as replicated.
See Also
MSSQL_ENG014005
Warehouse
Message Details
Event ID 14005
Symbolic Name
Message Text Could not drop publication. A subscription exists to it.
Explanation
You have tried to drop a publication which has one or more associated subscriptions. A publication can only be
dropped if there are no associated subscriptions.
User Action
Drop the subscriptions before dropping the publication. If you use SQL Server Management Studio to drop the
publication, it will give you the option to automatically drop all associated subscriptions before dropping the
publication. If you use stored procedures, you must explicitly drop the subscriptions first. For more information, see
Delete a Push Subscription and Delete a Pull Subscription.
If no subscriptions appear to exist for the publication or if you see this error when you create a publication, you
might have a previous subscription that was not completely cleaned up when it was removed. Execute
sp_removedbreplication (Transact-SQL) on the database to remove all objects and settings related to replication.
See Also
MSSQL_ENG014010
Warehouse
Message Details
Event ID 14010
Symbolic Name
Message Text The server '%s' is not defined as a subscription server.
Explanation
Replication expects all servers in a topology to be registered using the computer name with an optional instance
name (in the case of a clustered instance, the SQL Server virtual server name with the optional instance name). For
replication to function properly, the value returned by SELECT @@SERVERNAME for each server in the topology should
match the computer name or virtual server name with the optional instance name.
Replication is not supported if you have registered any of the SQL Server instances by IP address or by Fully
Qualified Domain Name (FQDN). If you have any of the SQL Server instances registered by IP address or by FQDN
in SQL Server Management Studio when you configured replication, this error could be raised.
User Action
Verify that all SQL Server instances in the topology are registered properly. If the network name of the computer
and the name of the SQL Server instance differ, either:
Add the SQL Server instance name as a valid network name. One method to set an alternative network
name is to add it to the local hosts file. The local hosts file is located by default at
WINDOWS\system32\drivers\etc or WINNT\system32\drivers\etc. For more information, see the Windows
documentation.
For example, if the computer name is comp1 and the computer has an IP address of 10.193.17.129, and the
instance name is inst1/instname, add the following entry to the hosts file:
10.193.17.129 inst1
Remove replication, register each SQL Server instance, and then reestablish replication. If the value of
@@SERVERNAME is not correct for a non-clustered instance, follow these steps:
sp_dropserver '<old_name>', 'droplogins'
go
sp_addserver '<new_name>', 'local'
go
After you execute the sp_addserver (Transact-SQL) stored procedure, you must restart the SQL Server
service for the change to @@SERVERNAME to take effect.
If the value of @@SERVERNAME is not correct for a clustered instance, you must change the name using
Cluster Administrator. For more information, see Always On Failover Cluster Instances (SQL Server).
See Also
@@SERVERNAME (Transact-SQL)
MSSQL_ENG014114
Warehouse
Message Details
Event ID 14114
Symbolic Name
Message Text '%s' is not configured as a Distributor.
Explanation
If the error message specifies a particular instance, rather than 'null', the instance specified has not been properly
configured to be recognized as a Distributor.
If the message specifies 'null' as a Distributor, there is no entry for the local server in master database, or the entry
is incorrect (perhaps because the computer was renamed). Replication expects all servers in a topology to be
registered using the computer name with an optional instance name (in the case of a clustered instance, the SQL
Server virtual server name with the optional instance name). For replication to function properly, the value
returned by SELECT @@SERVERNAME for each server in the topology should match the computer name or virtual
server name with the optional instance name.
Qualified Domain Name (FQDN). If you had any of the SQL Server instances registered by IP address or by FQDN
in SQL Server Management Studio when you configured replication, this error could be raised.
User Action
If the error message specifies a particular instance, configure the server as a Distributor. For more information, see
Configure Distribution.
If the message does not specify a particular instance ('null'), verify that the Distributor instance is registered
properly. If the network name of the computer and the name of the SQL Server instance differ, either:
documentation.
10.193.17.129 inst1
Disable distribution, register the instance, and then reestablish distribution. If the value of @@SERVERNAME
is not correct for a non-clustered instance, follow these steps:

go
go
Cluster Administrator. For more information, see Always On Failover Cluster Instances (SQL Server).
See Also
MSSQL_ENG014117
Warehouse
Message Details
Event ID 14117
Symbolic Name
Message Text '%s' is not configured as a distribution database.
Explanation
This error can occur if one or both of the following are true:
The entry for the specified distribution database is missing from msdb..MSdistributiondbs.
There is not an entry for the local server in the master database, or the entry that is there is incorrect.
Replication expects all servers in a topology to be registered using the computer name with an optional
instance name (in the case of a clustered instance, the SQL Server virtual server name with the optional
instance name). For replication to function properly, the value returned by SELECT @@SERVERNAME for each
server in the topology should match the computer name or virtual server name with the optional instance
name.
Qualified Domain Name (FQDN). If you had any of the SQL Server instances registered by IP address or by
FQDN in SQL Server Management Studio when you configured replication, this error could be raised.
User Action
Verify that the Distributor instance is registered properly. If the network name of the computer and the name of the
SQL Server instance differ, either:
documentation.
10.193.17.129 inst1
Disable distribution, register the instance, and then reestablish distribution. If the value of @@SERVERNAME
is not correct for a non-clustered instance, follow these steps:

go
go
Cluster Administrator. For more information, see AlwaysOn Failover Cluster Instances (SQL Server).
After verifying that the Distributor instance is registered properly, verify that the distribution database is
listed in msdb..MSdistributiondbs. If it is not listed:
1. Script out the distribution configuration. For more information, see Scripting Replication.
2. Disable distribution and then re-enable it. For more information, see Configure Distribution.
See Also
MSSQL_ENG014120
Warehouse
Message Details
Event ID 14120
Symbolic Name
Message Text Could not drop the distribution database '%s'. This distributor
database is associated with a Publisher.
Explanation
The distribution database stores metadata and history data for all types of replication and transactions for
transactional replication. This error occurs if you attempt to drop a distribution database that is associated with one
or more Publishers.
User Action
To drop a distribution database you must first drop the association between the Distributor and the Publisher. For
more information, see sp_dropdistpublisher (Transact-SQL).
See Also
MSSQL_ENG014121
Warehouse
Message Details
Event ID 14121
Symbolic Name
Message Text Could not drop the Distributor '%s'. This Distributor has
associated distribution databases.
Explanation
A SQL Server instance that is configured as a Distributor cannot be removed from the role of Distributor because
there are distribution databases associated with the instance. This error occurs if you attempt to drop a distribution
database that is associated with one or more Publishers.
User Action
To find the names of any Publishers and distribution databases associated with this Distributor, execute
sp_helpdistpublisher (Transact-SQL) from any database on the Distributor.
Execute sp_dropdistributiondb (Transact-SQL) for any distribution databases associated with this Distributor. After
all distribution database associations are removed, you can disable distribution.
See Also
MSSQL_ENG014144
Warehouse
Message Details
Event ID 14144
Symbolic Name
Message Text Cannot drop Subscriber '%s'. There are subscriptions for it in
the publication database '%s'.
Explanation
A SQL Server instance that is configured as a Subscriber cannot be removed from the role of Subscriber while
there are active subscriptions configured for the instance.
User Action
Drop all associated subscriptions before attempting to change the Subscriber status of the SQL Server instance:
1. Execute sp_helpsubscription (Transact-SQL) in the publication database at the Publisher to find
subscriptions.
2. Execute sp_dropsubscription (Transact-SQL) in the publication database to drop subscriptions.
See Also
MSSQL_ENG014150
Warehouse
Message Details
Event ID 14150
Symbolic Name
Message Text Replication-%s: agent %s succeeded. %s
Explanation
This message indicates that a replication agent has successfully finished running. Replication uses the following
agents:
The Snapshot Agent. This agent is used by all publications.
The Log Reader Agent. This agent is used by all transactional publications.
The Queue Reader Agent. This agent is used by transactional publications enabled for queued updating
subscriptions.
The Distribution Agent. This agent synchronizes subscriptions to transactional and snapshot publications.
The Merge Agent. This agent synchronizes subscriptions to merge publications.
Replication maintenance jobs.
User Action
The Log Reader Agent, Queue Reader Agent, and Distribution Agent typically run continuously, whereas the other
agents typically run on demand or on a schedule. If you do not expect an agent to have completed a run, check the
status of the agent. For more information, see Monitor Replication Agents.
See Also
MSSQL_ENG014151
Warehouse
Message Details
Event ID 14151
Symbolic Name
Message Text Replication-%s: agent %s failed. %s
Explanation
This error is raised for any replication agent failure. The text at the end of the message depends on the context of
the failure.
User Action
This error can occur in a number of situations; use the following approaches as necessary:
Restart the failed agent to see if it will now run without failures. For more information, see Start and Stop a
Replication Agent (SQL Server Management Studio) and Replication Agent Executables Concepts.
Check the agent history and job history for other errors that occurred around the same time. For
information about viewing agent status and error details in Replication Monitor, see the following topics:
For the Snapshot Agent, Log Reader Agent, and Queue Reader Agent, see View Information and
Perform Tasks for the Agents Associated With a Publication (Replication Monitor).
For the Distribution Agent and Merge Agent, see View Information and Perform Tasks for the Agents
Associated With a Subscription (Replication Monitor).
Verify that basic connectivity is working between the computers accessed by the agent, and then connect to
each computer with a utility like the sqlcmd Utility. When connecting, use the same account under which the
agent makes connections. For more information about the permissions required by each agent account, see
If the error occurs while creating or applying a snapshot, check the files in the snapshot directory for errors.
If the error continues to occur, increase the logging of the agent and specify an output file for the log.
Depending on the context of the error, this could provide the steps leading up to the error and/or additional
error messages.
See Also
MSSQL_ENG014152
Warehouse
Message Details
Event ID 14152
Symbolic Name
Message Text Replication-%s: agent %s scheduled for retry. %s
Explanation
The specified replication agent has been scheduled to retry the requested operation. The process continues to retry
until it reaches the configured maximum number of retry attempts for the job step.
A retry typically occurs because of one of the following reasons:
The QueryTimeout value is exceeded.
The LoginTimeout value is exceeded.
The replication process was chosen as a deadlock victim.
User Action
If the retry message is infrequent, no user action is required.
Use sp_help_jobstep to view the current setting for the maximum number of times the Run agent step for the
specified replication agent will retry. You can use the @retry_attempts parameter of the sp_update_jobstep stored
procedure to adjust the number of times a job step retries.
If the retry message recurs frequently, troubleshoot the issue based on the message that is causing the retry. Check
the agent's history for messages that indicate why the retry had to be scheduled. In some cases you may have to
enable more detailed logging for your replication agent. For more information about how to configure logging for
replication, see the Microsoft Knowledge Base article 312292.
See Also
MSSQL_ENG014157
Warehouse
Message Details
Event ID 14157
Symbolic Name
Message Text The subscription created by Subscriber '%s' to publication '%s'

has expired and has been dropped.
Explanation
A Subscriber must synchronize with the Publisher within the time specified in the publication retention period. If a
Subscriber does not synchronize within this period, the subscription expires. For more information, see
Subscription Expiration and Deactivation.
User Action
The subscription must be re-created and initialized before the Subscriber can begin receiving data changes again:
For information about creating subscriptions, see Subscribe to Publications.
For information about initializing subscriptions, see Initialize a Subscription.
If the subscription database contains changes that have not been synchronized with the Publisher, you can
use the tablediff Utility to determine which rows are different in the publication and subscription databases.
You can increase the publication retention period to avoid having subscriptions expire. Use caution in setting
a high value, because this can result in more data and metadata being stored, which affects performance.
For more information, see Subscription Expiration and Deactivation.
See Also
MSSQL_ENG014160
Warehouse
Message Details
Event ID 14160
Symbolic Name
Message Text The threshold [%s:%s] for the publication [%s] has been set.
One or more subscriptions to this publication have expired.
Explanation
Replication lets you enable warnings for several conditions. This includes imminent subscription expiration.
Subscriptions can expire if they are not synchronized within a specified retention period. For more information, see
When you enable a warning by using Replication Monitor or sp_replmonitorchangepublicationthreshold, you
specify a threshold that determines when a warning is triggered. When that threshold is met or exceeded, a
warning is displayed in Replication Monitor, and an event is written to the Windows event log. Reaching a
threshold can also trigger a SQL Server Agent alert. For more information, see Set Thresholds and Warnings in
Replication Monitor and Programmatically Monitor Replication.
User Action
The resolution for this issue depends on the reason the warning was raised:
If the threshold has been exceeded, but the subscription has not yet expired, synchronize the subscription.
For more information, see Synchronize Data.
If the agent has been running, but has not been replicating changes properly, this can cause the subscription
to expire. For transactional replication, make sure that the Distribution Agent and Log Reader Agent are
running. For merge replication, make sure the Merge Agent is running. For information about how to start
these agents, see Start and Stop a Replication Agent (SQL Server Management Studio) and Replication
Agent Executables Concepts.
If the subscription has expired, it must either be reinitialized or dropped and re-created, depending on the
type of subscription and how long it has been expired. For more information, see Subscription Expiration
and Deactivation.
See Also
MSSQL_ENG014161
Warehouse
Message Details
Event ID 14161
Symbolic Name
Make sure that the logreader and distribution agents are
running and can match the latency requirement.
Explanation
Replication lets you enable warnings for several conditions. This includes exceeding a specified latency for
transactional subscriptions. Latency is the period of time that elapses between a data change being committed at
the Publisher and the corresponding change being committed at the Subscriber.
User Action
If a subscription exceeds a latency threshold, you must determine whether there is a performance issue with the
system or whether the threshold should be adjusted. After you configure replication, develop a performance
baseline that will let you determine how replication behaves with a workload that is typical for your applications
and topology. Include latency in this baseline so that you can set an appropriate value for the threshold.
If the threshold value is appropriate, but it is being exceeded, you must determine where the performance
bottleneck is in the system. For more information about how to monitor and troubleshoot replication performance,
see the following topics:
See Also
MSSQL_ENG014162
Warehouse
Message Details
Event ID 14162
Symbolic Name
Explanation
Replication lets you enable warnings for several conditions. This includes exceeding a specified length of time for
synchronizing changes between a merge Publisher and Subscriber. Different times can be specified for LAN
connections and dial-up connections.
User Action
If a subscription exceeds a duration threshold, you must determine whether there is a performance issue with the
and topology. Include duration of synchronization in this baseline so that you can set an appropriate value for the
threshold.
Monitor Performance with Replication Monitor (especially the section "Viewing Detailed Synchronization
Performance for Merge Replication")
See Also
MSSQL_ENG014163
Warehouse
Message Details
Event ID 14163
Symbolic Name
Explanation
Replication lets you enable warnings for several conditions. This includes exceeding a specified length of time for
synchronizing changes between a merge Publisher and Subscriber. Different times can be specified for LAN
connections and dial-up connections.
User Action
If a subscription exceeds a duration threshold, you must determine whether there is a performance issue with the
and topology. Include duration of synchronization in this baseline so that you can set an appropriate value for the
threshold.
See Also
MSSQL_ENG014164
Warehouse
Message Details
Event ID 14164
Symbolic Name
Explanation
Replication lets you enable warnings for several conditions. This includes failure to process a sufficient number of
rows when synchronizing changes between a merge Publisher and Subscriber. Different times can be specified for
LAN connections and dial-up connections.
User Action
If a subscription is not meeting a row processing threshold, you must determine whether there is a performance
issue with the system or whether the threshold should be adjusted. After you configure replication, develop a
performance baseline that will let you determine how replication behaves with a workload that is typical for your
applications and topology. Include number of rows processed in this baseline so that you can set an appropriate
value for the threshold.
See Also
MSSQL_ENG014165
Warehouse
Message Details
Event ID 14165
Symbolic Name
Explanation
Replication lets you enable warnings for several conditions. This includes failure to process a sufficient number of
rows when synchronizing changes between a merge Publisher and Subscriber. Different times can be specified for
LAN connections and dial-up connections.
User Action
If a subscription is not meeting a row processing threshold, you must determine whether there is a performance
issue with the system or whether the threshold should be adjusted. After you configure replication, develop a
performance baseline that will let you determine how replication behaves with a workload that is typical for your
applications and topology. Include number of rows processed in this baseline so that you can set an appropriate
value for the threshold.
See Also
MSSQL_ENG018456
Warehouse
Message Details
Event ID 18456
Symbolic Name
Message Text Login failed for user '%.*ls'.%.*ls
Explanation
Error MSSQL_ENG018456 is raised whenever a login attempt fails. If the error message includes the account
distributor_admin (Login failed for user 'distributor_admin'.), the issue is with an account used by replication.
Replication creates a remote server, repl_distributor, which allows communication between the Distributor and
Publisher. The login distributor_admin is associated with this remote server and must have a valid password.
User Action
Ensure that you have specified a password for this account. For more information, see Secure the Distributor.
See Also
MSSQL_ENG018752
Warehouse
Message Details
Event ID 18752
Symbolic Name
Message Text Only one Log Reader Agent or log-related procedure

(sp_repldone, sp_replcmds, and sp_replshowcmds) can connect
to a database at a time. If you executed a log-related
procedure, drop the connection over which the procedure was
executed or execute sp_replflush over that connection before
starting the Log Reader Agent or executing another log-
related procedure.
Explanation
More than one current connection is trying to execute any of the following: sp_repldone, sp_replcmds, or
sp_replshowcmds. The stored procedures sp_repldone (Transact-SQL) and sp_replcmds (Transact-SQL) are stored
procedures used by the Log Reader Agent to locate and update information about replicated transactions in a
published database. The stored procedure sp_replshowcmds (Transact-SQL) is used to troubleshoot certain types
of issues with transactional replication.
This error is raised in the following circumstances:
If the Log Reader Agent for a published database is running and a second Log Reader Agent attempts to run
against the same database, the error is raised for the second agent and appears in the agent history.
In a situation where it appears there are multiple agents, it is possible that one of them is the result of an
orphaned process.
If the Log Reader Agent for a published database is started and a user executes sp_repldone, sp_replcmds,
or sp_replshowcmds against the same database, the error is raised in the application where the stored
procedure was executed (such as sqlcmd).
If no Log Reader Agent is running for a published database and a user executes sp_repldone, sp_replcmds,
or sp_replshowcmds and then does not close the connection over which the procedure was executed, the
error is raised when the Log Reader Agent attempts to connect to the database.
User Action
The following steps can help you to troubleshoot the problem. If any step allows the Log Reader Agent to start
without errors, there is no need to complete the remaining steps.
Check the history of the Log Reader agent for any other errors that could be contributing to this error. For
information about viewing agent status and error details in Replication Monitor, see View Information and
Check the output of sp_who (Transact-SQL) for specific process identification numbers (SPIDs) that are
connected to the published database. Close any connections that might have run sp_repldone,
sp_replcmds, or sp_replshowcmds.
Restart the Log Reader Agent. For more information, see Start and Stop a Replication Agent (SQL Server
Management Studio).
Restart the SQL Server Agent service (bring it offline or online in a cluster) on the Distributor. If there is
possibility that a scheduled job could have executed sp_repldone, sp_replcmds, or sp_replshowcmds
from any other SQL Server instance, restart the SQL Server Agent for those instances as well. For more
information, see Start, Stop, or Pause the SQL Server Agent Service.
Execute sp_replflush (Transact-SQL) at the Publisher on the publication database, and then restart the Log
Reader Agent.
Depending on the context of the error, this could provide the steps leading up to the error and/or additional
error messages.
See Also
MSSQL_ENG020554
Warehouse
Message Details
Event ID 20554
Symbolic Name
Message Text The replication agent has not logged a progress message in
%ld minutes. This might indicate an unresponsive agent or
high system activity. Verify that records are being replicated to
the destination and that connections to the Subscriber,
Publisher, and Distributor are still active.
Explanation
The Replication agents checkup job runs at a specified interval (10 minutes by default) to check on the status of
each replication agent. If an agent has not logged any progress messages since the last time the agent checkup job
ran, error MSSQL_ENG020554 can be raised. The agent is expected at least to log history messages even if no
other replication activity is occurring. Although the replication agent is not responding as expected, it has not
necessarily stopped or failed (if an agent has failed, error MSSQL_ENG020536 should be raised).
The following issues can cause error MSSQL_ENG020554 to be raised:
The agent is busy.
If the agent is too busy to respond when polled by the agent checkup job, the agent checkup job cannot
report whether the replication agent is functioning properly. There are a number of reasons why the
replication agent could be busy: there might be a lot of data being replicated, or there might be application
design or configuration issues that result in processes that run for a long time.
The agent cannot log in to one of the computers in the topology.
All agents have a parameter -LoginTimeOut (set to 15 seconds by default), which governs how long an
agent attempts to log in to a replication node, such as a Merge Agent logging in to the Publisher. If the -
LoginTimeOut value is set higher than the interval at which the replication agent checkup job runs, a login
problem could be the root cause of the error: error MSSQL_ENG020554 is raised before the agent is able to
raise a more specific error.
User Action
The action required depends on the cause of the error:
For all cases in which this error is raised:
Check the error details in Replication Monitor, and then restart the agent if it has stopped. The error details
might provide additional information on why the agent was not running properly. If the agent is running, do
not stop and restart the agent, because that can exacerbate the problem. For information about viewing
agent status and error details in Replication Monitor, see the following topics:
If this error is raised frequently because the agent is busy:
You might need to redesign your application so that the agent spends less time processing.
You can increase the interval at which agent status is checked using the Job Properties dialog box. For
information about accessing this dialog box for replication jobs, see View Information and Perform Tasks for
a Publisher (Replication Monitor).
If an agent cannot log in to one of the computers in the topology:
We recommend that the -LoginTimeOut value be set lower than the interval at which the replication agent
checkup job runs. In some cases, the value for -LoginTimeOut is set higher because of network issues that
cause logins to time out. If the -LoginTimeOut is set lower, replication can report more specific errors,
allowing you to troubleshoot login problems that could be caused by permissions, network problems, or
other issues. Agent parameters can be specified in agent profiles and on the command line. For more
information, see:
View and Modify Replication Agent Command Prompt Parameters (SQL Server Management Studio)
Replication Agent Executables Concepts.
See Also
MSSQL_ENG020557
Warehouse
Message Details
Event ID 20557
Symbolic Name
Message Text Agent shutdown. For more information, see the SQL Server
Agent job history for job '%s'.
Explanation
A replication agent has shut down without writing a reason to the appropriate history table, or the agent was shut
down while in the middle of a process.
User Action
Restart the agent to see whether it will now run without failures. For more information, see Start and Stop a
Replication Agent (SQL Server Management Studio) and Replication Agent Executables Concepts.
Check the agent history and job history for other errors that occurred around the same time. For
information about how to view agent status and error details in Replication Monitor, see the following
topics:
Verify that basic connectivity is working between the computers that are accessed by the agent, and then
connect to each computer by using a utility, such as the sqlcmd utility. When you connect, use the same
account under which the agent makes connections. For more information about the permissions that are
required by each agent account, see Replication Agent Security Model.
If the error occurs while you are creating or applying a snapshot, check the files in the snapshot directory for
errors.
Depending on the context of the error, this could provide the steps leading up to the error and additional
error messages. For more information about how to configure logging for replication, see the Microsoft
Knowledge Base article 312292.
See Also
MSSQL_ENG020572
Warehouse
Message Details
Event ID 20572
Symbolic Name
Message Text Subscriber '%s' subscription to article '%s' in publication '%s'

has been reinitialized after a validation failure.
Explanation
The data at the Subscriber was validated against the data at the Publisher, and the data did not match; therefore
validation failed. When you specified that validation should be performed, you selected the option that a
subscription should be reinitialized if validation failed. Reinitializing a subscription involves applying a new
snapshot at the Subscriber. For more information about validation, see Validate Replicated Data.
User Action
Data at the Publisher and Subscriber will match after the new snapshot is applied at the Subscriber.
See Also
MSSQL_ENG020574
Warehouse
Message Details
Event ID 20574
Symbolic Name

failed data validation.
Explanation
The data at the Subscriber was validated against the data at the Publisher, and the data did not match; therefore
validation failed. For more information about validation, see Validate Replicated Data.
User Action
We recommend that you do the following:
Determine why validation failed.
Correct the underlying issue that caused the failure.
Bring the data into convergence by reinitializing the subscription or through another method.
See Also
MSSQL_ENG020575
Warehouse
Message Details
Event ID 20575
Symbolic Name

passed data validation.
Explanation
The data at the Subscriber was validated against the data at the Publisher, and the data matched; therefore
validation passed. For more information about validation, see Validate Replicated Data.
See Also
MSSQL_ENG020596
Warehouse
Message Details
Event ID 20596
Symbolic Name
Message Text Only '%s' or members of db_owner can drop the anonymous
agent.
Explanation
You do not have sufficient permissions to drop the agent for the anonymous subscription. The login used when
calling sp_dropanonymousagent (Transact-SQL) must be a member of the sysadmin fixed server role at the
Distributor or db_owner fixed database role in the distribution database, or the user must be the one that initiated
the first run of the agent.
User Action
Login with the appropriate credentials, and execute sp_dropanonymousagent.
See Also
MSSQL_ENG020598
Warehouse
Message Details
Event ID 20598
Symbolic Name
Message Text The row was not found at the Subscriber when applying the
replicated command.
Explanation
This error is raised in transactional replication if the Distribution Agent attempts to update a row at the Subscriber,
but the row has been deleted or the primary key of the row has been changed. By default, Subscribers to
transactional publications should be treated as read-only, because changes are not propagated back to the
Publisher. For transactional replication, user changes should be made at the Subscriber only if updatable
subscriptions or peer-to-peer replication is used. For information about these options, see Updatable Subscriptions
for Transactional Replication and Peer-to-Peer Transactional Replication.
User Action
To resolve this problem:
1. If replication must continue while you identify the source of the error, specify the parameter -SkipErrors
20598 for the Distribution Agent. This allows the agent to skip changes that result in error 20598, while
allowing other changes to be replicated.
2. Identify which rows at the Subscriber have been deleted or have a different primary key than the
corresponding rows at the Publisher. You can use the tablediff Utility to determine which rows are different
in the publication and subscription databases. For information about using this utility with replicated
databases, see Compare Replicated Tables for Differences (Replication Programming).
3. Correct the rows at the Subscriber using the tablediff utility or another method.
4. (Optional) Remove the -SkipErrors parameter.
See Also
MSSQL_ENG021075
Warehouse
Message Details
Event ID 21075
Symbolic Name
Message Text The initial snapshot for publication '%s' is not yet available.
Explanation
Error MSSQL_ENG021075 is raised if the Distribution Agent or Merge Agent is started before the Snapshot Agent
has finished generating the snapshot.
User Action
If the Snapshot Agent for the publication has not been started since the subscription was created, or if it has not
been started since the last time you chose to reinitialize the subscription, start the Snapshot Agent and let it
complete before starting the Distribution Agent or Merge Agent. For more information, see Create and Apply the
Snapshot.
If the Snapshot Agent does not complete, check the Snapshot Agent history for errors and address them. For
information about viewing agent status and error details in Replication Monitor, see View Information and Perform
Tasks for the Agents Associated With a Publication (Replication Monitor).
If the error continues to occur, increase the logging of the agent and specify an output file for the log. Depending
on the context of the error, this could provide the steps leading up to the error and/or additional error messages.
See Also
MSSQL_ENG021076
Warehouse
Message Details
Event ID 21076
Symbolic Name
Message Text The initial snapshot for article '%s' is not yet available.
Explanation
Error MSSQL_ENG021076 can be raised if the Distribution Agent is started before the Snapshot Agent has finished
generating the snapshot. This error is raised only if the publication contains a single article. If the publication
contains more than one article, MSSQL_ENG021075 is raised instead. For more information, see
MSSQL_ENG021075.
User Action
If the Snapshot Agent for the publication has not been started since the subscription was created, or if it has not
been started since the last time you chose to reinitialize the subscription, start the Snapshot Agent and let it
complete before starting the Distribution Agent. For more information, see Create and Apply the Snapshot.
If the Snapshot Agent does not complete, check the Snapshot Agent history for errors and address them. For
information about viewing agent status and error details in Replication Monitor, see View Information and Perform
Tasks for the Agents Associated With a Publication (Replication Monitor).
If the error continues to occur, increase the logging of the agent and specify an output file for the log. Depending
on the context of the error, this could provide the steps leading up to the error and/or additional error messages.
See Also
MSSQL_ENG021286
Warehouse
Message Details
Event ID 21286
Symbolic Name
Message Text Conflict table '%s' does not exist.
Explanation
This error is raised if the conflict table for an article listed in sysmergearticles (Transact-SQL) does not actually exist.
The error can occur when you attempt to add a column to or drop a column from a table published for merge
replication.
User Action
Execute DBCC CHECKDB (Transact-SQL) on the database with the missing conflict table to verify there are no data
consistency issues.
If the conflict table is missing on a Subscriber, drop the subscription and recreate it. If the conflict table is missing
on a Publisher, drop all subscriptions, drop the publication, and then recreate the publication and all subscriptions.
For more information, see Publish Data and Database Objects and Subscribe to Publications.
See Also
MSSQL_ENG021330
Warehouse
Message Details
Event ID 21330
Symbolic Name
Message Text Failed to create a sub-directory under the replication working

directory.(%ls)
Explanation
This error can occur when a subscription is initialized manually, and there is a problem creating the directory in
which replication scripts are stored. The error can be caused by a permissions issue: when a subscription is
initialized without using a snapshot, the account under which the SQL Server service runs at the Publisher must
have write permissions on the snapshot folder at the Distributor.
User Action
Ensure that the correct path has been specified for the snapshot folder and that the account under which the SQL
Server service runs at the Publisher has sufficient permissions.
See Also
MSSQL_ENG021331
Warehouse
Message Details
Event ID 21331
Symbolic Name
Message Text Failed to copy user script file to the Distributor.(%ls)
Explanation
This error can occur when a subscription is initialized manually, and the scripts generated by replication, or
specified in a replication command, cannot be saved to the specified directory. The error can be caused by a
permissions issue: when a subscription is initialized without using a snapshot, the account under which the SQL
Server service runs at the Publisher must have write permissions on the snapshot folder at the Distributor.
User Action
Ensure that the correct path has been specified for the snapshot folder and that the account under which the SQL
Server service runs at the Publisher has sufficient permissions.
See Also
MSSQL_ENG021385
Warehouse
Message Details
Event ID 21385
Symbolic Name
Message Text Snapshot failed to process publication '%s'. Possibly due to

active schema change activity or new articles being added.
Explanation
This error is raised if the Snapshot Agent starts running when there are ongoing changes to the publication
database, including adding or dropping articles and performing schema changes on published objects.
User Action
Restart the Snapshot Agent after changes to the publication database are complete. For more information, see Start
and Stop a Replication Agent (SQL Server Management Studio) and Replication Agent Executables Concepts.
See Also
MSSQL_ENG021797
Warehouse
Message Details
Event ID 21797
Symbolic Name
Message Text '%s' must be a valid Windows Login in the form:

'MACHINE\Login' or 'DOMAIN\Login'. Please see the
documentation for '%s'.
Explanation
This error is raised by the following replication stored procedures if the value specified for the @job_login
parameter is null or not valid. This error can occur if a member of the db_owner fixed database role runs scripts
from previous versions of SQL Server. The security model changed in SQL Server 2005, and these scripts must be
updated.
sp_addlogreader_agent (Transact-SQL)
sp_addqreader_agent (Transact-SQL)
sp_addpublication_snapshot (Transact-SQL)
sp_addpushsubscription_agent (Transact-SQL)
sp_addpullsubscription_agent (Transact-SQL)
sp_addmergepushsubscription_agent (Transact-SQL)
sp_addmergepullsubscription_agent (Transact-SQL)
These stored procedures can be executed by a member of the sysadmin fixed server role on the appropriate
server or a member of the db_owner fixed database role in the appropriate database. The stored
procedures each create an agent job and allow you to specify the Microsoft Windows account under which
the agent runs. For users in the sysadmin role, agent jobs are created implicitly even if a Windows account
is not specified (if an account is specified, it must be valid); agents run under the context of the SQL Server
Agent service account at the appropriate server. Although the account is not required, it is a security best
practice to specify a separate account for the agents. For more information, see Replication Agent Security
Model.
User Action
Ensure you specify a valid Windows account for the @job_login parameter of each procedure. If you have
replication scripts from previous versions of SQL Server, update these scripts to include the stored procedures and
parameters required by SQL Server 2005. For more information, see Upgrade Replication Scripts (Replication
See Also
MSSQL_ENG021798
Warehouse
Message Details
Event ID 21798
Symbolic Name
Message Text The '%s' agent job must be added through '%s' before
continuing. Please see the documentation for '%s'.
Explanation
To create a publication, you must be a member of the sysadmin fixed server role on the Publisher or a member of
the db_owner fixed database role in the publication database. If you are a member of the db_owner role, this
error is raised if:
You run scripts from SQL Server 2000. The security model changed in SQL Server 2005, and these scripts
must be updated.
The stored procedure sp_addpublication is executed before executing sp_addlogreader_agent (Transact-
SQL). This applies to all transactional publications.
The stored procedure sp_addpublication is executed before executing sp_addqreader_agent (Transact-
SQL). This applies to transactional publications that are enabled for queued updating subscriptions (a value
of TRUE for the @allow_queued_tran parameter of sp_addpublication).
The stored procedures sp_addlogreader_agent and sp_addqreader_agent each create an agent job and
allow you to specify the Microsoft Windows account under which the agent runs. For users in the sysadmin
role, agent jobs are created implicitly if sp_addlogreader_agent and sp_addqreader_agent are not
executed; agents run under the context of the SQL Server Agent service account at the Distributor. Although
sp_addlogreader_agent and sp_addqreader_agent are not required for users in the sysadmin role, it is
a security best practice to specify a separate account for the agents. For more information, see Replication
Agent Security Model.
User Action
Ensure you execute procedures in the correct order. For more information, see Create a Publication. If you have
replication scripts from previous versions of SQL Server, update these scripts to include the stored procedures and
parameters required by SQL Server 2005 and later versions. For more information, see Upgrade Replication Scripts
(Replication Transact-SQL Programming).
See Also
MSSQL_ENG024070
Warehouse
Message Details
Event ID 24070
Symbolic Name
Message Text A required privilege is not held by the client.
Explanation
This is a general error that can be raised regardless of whether replication is being used. For a server in a
replication topology, the error is typically raised because the SQL Server Agent service account is changed by using
the Microsoft Windows Service Control Manager instead of SQL Server Configuration Manager. When you try to
run an agent job after changing the service account, the job might fail with an error message that is similar to the
following:
Executed as user: \<UserAccount>. Replication-Replication Snapshot Subsystem: agent \<AgentName> failed.
Executed as user: \<UserAccount>. A required privilege is not held by the client. The step failed. [SQLSTATE
42000] (Error 14151). The step failed.
This problem occurs because the Windows Service Control Manager cannot grant the required permissions to the
new service account for SQL Server Agent.
User Action
To avoid this problem in the future, always use SQL Server Configuration Manager instead of the Windows Service
Control Manager to change service accounts and passwords.
To resolve this problem, use SQL Server Configuration Manager to change the service account back to the original
account. Then, use SQL Server Configuration Manager to change to the new account. When you do this, SQL Server
Configuration Manager adds the new account to the following security group:
SQLServer2008SQLAgentUser$ComputerName$InstanceName
Being a member of this security group grants to the new account the required permissions to run the replication
agent job.
See Also
SQL Server Configuration Manager
MSSQL_REPL020011
Warehouse
Message Details
Event ID 20011
Symbolic Name
Message Text The process could not execute '%1' on '%2'.
Explanation
This error can be raised in a number of circumstances during transactional replication processing, such as when the
Log Reader Agent executes sp_replcmds (The process could not execute 'sp_replcmds' on <ServerName>) or
sp_repldone (The process could not execute 'sp_repldone' on <ServerName>).
User Action
If this error is raised in a database that you have just restored from a backup, ensure you have followed the steps
outlined in the backup and restore documentation, including executing sp_replrestart if appropriate. For more
information, see Strategies for Backing Up and Restoring Snapshot and Transactional Replication.
This error is an internal processing error and if it is raised in circumstances other than a restore, it typically
indicates that replication must be removed and reconfigured. If you cannot remove replication, contact customer
support for assistance.
See Also
sp_replcmds (Transact-SQL)
sp_repldone (Transact-SQL)
MSSQL_REPL027056
Warehouse
Message Details
Event ID 27056
Symbolic Name
Message Text The merge process was unable to change generation history
at the '%1'. When troubleshooting, restart the synchronization
with verbose history logging and specify an output file to
which to write.
Explanation
This error is typically raised as a result of contention in merge replication system tables that have grown
excessively large. Large system tables are typically caused by a long publication retention period, because metadata
must be stored in these tables until the retention period is reached.
User Action
To resolve the issue:
1. Decrease the value of the -DownloadGenerationsPerBatch and -UploadGenerationsPerBatch
parameters for the Merge Agent to allow processing to continue while you address the underlying issue
causing the error. Agent parameters can be specified in agent profiles and on the command line. For more
information, see:
2. Specify the lowest setting possible for the publication retention period. For more information, see
3. As part of maintenance for merge replication, occasionally check the growth of the system tables associated
with merge replication: MSmerge_contents, MSmerge_genhistory, and MSmerge_tombstone,
MSmerge_current_partition_mappings, and MSmerge_past_partition_mappings. Periodically re-index
these tables. For more information, see Reorganize and Rebuild Indexes.
See Also
MSSQL_REPL027183
Warehouse
Message Details
Event ID 27183
Symbolic Name
Message Text The merge process failed to enumerate changes in articles

with parameterized row filters. If this failure continues, increase
the query timeout for this process, reduce the retention
period for the publication, and improve indexes on published
tables.
Explanation
This error is raised if a Merge Agent timeout occurs while processing changes in a filtered publication. The timeout
might be caused by one of the following issues:
Not using the precomputed partitions optimization.
Index fragmentation on columns used for filtering.
Large merge metadata tables, such as MSmerge_tombstone, MSmerge_contents, and
MSmerge_genhistory.
Filtered tables that are not joined on a unique key and join filters that involve a large number of tables.
User Action
To resolve the issue:
Increase the value of the -QueryTimeOut parameter for the Merge Agent to allow processing to continue
while you address the underlying issues causing the error. Agent parameters can be specified in agent
profiles and on the command line. For more information, see:
Use the precomputed partitions optimization if possible. This optimization is used by default if a number of
publication requirements are met. For more information about these requirements, see Optimize
Parameterized Filter Performance with Precomputed Partitions. If the publication does not meet these
requirements, consider redesigning the publication.
Specify the lowest setting possible for the publication retention period, because replication cannot clean up
metadata in the publication and subscription databases until the retention period is reached. For more
information, see Subscription Expiration and Deactivation.
As part of maintenance for merge replication, occasionally check the growth of the system tables associated
with merge replication: MSmerge_contents, MSmerge_genhistory, and MSmerge_tombstone,
MSmerge_current_partition_mappings, and MSmerge_past_partition_mappings. Periodically re-index
these tables. For more information, see Reorganize and Rebuild Indexes.
Ensure that columns used for filtering are properly indexed and rebuild such indexes if necessary. For more
information, see Reorganize and Rebuild Indexes.
Set the join_unique_key property for join filters that are based on unique columns. For more information,
see Join Filters.
Limit the number of tables in the join filter hierarchy. If you are generating join filters of five or more tables,
consider other solutions: do not filter tables that are small, not subject to change, or are primarily lookup
tables. Use join filters only between tables that must be partitioned among subscriptions.
Make a smaller number of changes on filtered tables between synchronizations, or run the Merge Agent
more frequently. For more information about setting synchronization schedules, see Specify
See Also
Warehouse
Message Details
Event ID -2147198698
Event Source MSSQLServer
Symbolic Name
Message Text The snapshot for this publication has become obsolete. The
snapshot agent needs to be run again before the subscription
can be synchronized.
Explanation
The snapshot for this publication has become obsolete.
User Action
The Snapshot Agent must to be run again before the subscription can be synchronized.
Internal-Only
Warehouse
Message Details
Event ID -2147199363
Symbolic Name
Message Text The merge process failed because it detected a mismatch

between the replication metadata of the two replicas, such
that some changes could be lost leading to non-convergence.
This could be due to the subscriber not synchronizing within
the retention period, or because one of the replicas was
restored to a backup older than retention period, or because
the publisher performed more aggressive cleanup on articles
of type download-only and articles with partition_options = 3.
Explanation
The merge process failed because it detected a mismatch between the replication metadata of the two replicas. This
means that some changes could be lost, which could cause non-convergence.
User Action
Restore the replica to a more recent backup, or reinitialize the merge process without uploading data first.
Internal-Only
Warehouse
Message Details
Event ID -2147199371
Symbolic Name
Message Text The request that was sent to the IIS server was greater than 4
GB, which is not supported. Try using a smaller value for the
'UploadGenerationsPerBatch' parameter.
Explanation
When you are using Web synchronization, the size of the uploaded message must not be larger than 4 GB.
User Action
Decrease the value for the UploadGenerationsPerBatch parameter.
Internal-Only
Warehouse
Message Details
Event ID -2147199376
Symbolic Name
Message Text One or more articles in the publication are configured to have
non-overlapping partitions that are unique for each
subscription, and there is already another subscription with
the same partition. Drop any unused subscription registrations
for this partition or change the partitioning options for the
article.
Explanation
When a publication contains one or more articles that were configured by using partition_options=3, the merge
process checks to make sure that there is only one subscription per partition.
User Action
If the publication contains stale subscriptions, drop these subscriptions by using sp_dropmergesubscription.
Internal-Only
Warehouse
Message Details
Event ID -2147199389
Symbolic Name
Message Text This publication differs from the publication to which the
subscription was initially created. The original publication may
have been deleted and replaced with a new publication with
the same name. At the subscriber, delete the subscription and
recreate it for the new publication.
Explanation
This publication differs from the publication to which the subscription was initially created.
User Action
Add the name of the publication to this message.
Internal-Only
Warehouse
Message Details
Event ID -2147199390
Symbolic Name
Message Text The Merge Agent failed to retrieve the snapshot schema script
file '%1'. Run the Snapshot Agent to regenerate the snapshot
files for this publication. If delivering the snapshot using FTP,
ensure that the account under which the agent runs has
access to the FTP directory.
Explanation
There is no file associated with the schema change that has to be applied. A failure might have occurred while
generating the snapshot or obtaining the snapshot files through FTP.
User Action
Try to rerun Snapshot Agent.
Internal-Only
Warehouse
Message Details
Event ID -2147199398
Symbolic Name
Message Text The Merge Agent failed because the schema of the article at
the Publisher does not match the schema of the article at the
Subscriber. This can occur when there are pending DDL
changes waiting to be applied at the Subscriber. Restart the
Merge Agent to apply the DDL changes and synchronize the
subscription.
Explanation
When the merge process is propagating changes from the Subscriber to the Publisher, it compares the version of
the replication stored procedures that is being used by the Merge Agent with the version of the stored procedures
at the Publisher. If a DDL change occurred while the merge process was running, a schema mismatch could be
detected.
User Action
Retrying the merge process should fix the problem, because the Merge Agent will start using the version of the
replication stored procedures present at the Publisher.
Internal-Only
Warehouse
Message Details
Event ID -2147199401
Symbolic Name
Message Text The Merge Agent failed after detecting that retention-based
metadata cleanup has deleted metadata at the Subscriber for
changes not yet sent to the Publisher. You must reinitialize the
subscription (without upload).
Explanation
The merge process failed because it detected that retention-based metadata cleanup at the Subscriber has deleted
metadata for changes that have not been sent to the Publisher.
User Action
Reinitialize the subscription by specifying @upload_first = 'FALSE'.
Internal-Only
Warehouse
Message Details
Event ID -2147199402
Symbolic Name
Message Text The Merge Agent failed after detecting that retention-based
metadata cleanup has deleted metadata at the Publisher for
changes not yet sent to the Subscriber. You must reinitialize
the subscription (without upload).
Explanation
The merge process failed because it detected that retention-based metadata cleanup at the Subscriber has deleted
metadata for changes that have not been sent to the Publisher.
Cau t i on
Error -2147199402 may also be caused by other problems with the metadata, such as configuring the publication
for aggressive cleanup or subscriber syncing outside of the retention period.
User Action
Reinitialize the subscription by using @upload_first = 'FALSE'.
NOTE
The last sync date can be found in the sysmergesubscriptions table.
Internal-Only
Warehouse
Message Details
Event ID -2147199416
Symbolic Name
Message Text The Merge Agent failed to obtain a new set of identity ranges
for the Subscriber. When troubleshooting, restart the Merge
Agent with a higher value for -HistoryVerboseLevel and check
the output log files for other server-related errors. Resolve any
server-related errors before restarting the synchronization, or
reinitialize the subscription.
Explanation
The merge process failed. This might have occurred because the identity range check constraint could not be
dropped and re-created.
User Action
If the identity range check constraint could not be dropped and re-created, check the security permissions, and also
check whether the DDL changes are allowed on the table.
If the merge process could not find the Subscriber's identity range allocation entry, reinitializing the subscriber
might fix the problem. The merge process that applies the snapshot creates the entry for the identity range
allocation in the table.
Internal-Only
Warehouse
Message Details
Event ID -2147199417
Symbolic Name
Message Text The Publisher failed to allocate a new set of identity ranges for
the subscription. This can occur when a Publisher or a
republishing Subscriber has run out of identity ranges to
allocate to its own Subscribers or when an identity column
data type does not support an additional identity range
allocation. If a republishing Subscriber has run out of identity
ranges, synchronize the republishing Subscriber to obtain
more identity ranges before restarting the synchronization. If a
Publisher runs out of identity ranges, verify that the size of the
data type supports the needed identity ranges.
Explanation
The merge process failed. This might have occurred because either the top-level Publisher or republisher could not
allocate a new range. In the Publisher case, the Publisher's identity range allocation could not be increased. This is
because the range needed to allocate exceeds the maximum or minimum value allowed for the data type. In the
republisher case, the republisher has run out of the republishing range for allocation.
User Action
To allocate a new republishing range, run the merge between the republisher and the top-level Publisher to allocate
more range to the republisher. If the Publisher runs out of range, evaluate the data type used for the identity
column.
Internal-Only
Warehouse
Message Details
Event ID -2147199420
Symbolic Name
Message Text The Merge Agent failed to determine whether the subscription
has expired. When troubleshooting, use SQL Server Profiler or
restart the agent with a higher value for -HistoryVerboseLevel
and check the output log file for errors. Correct any database
engine conditions that may be causing internal replication
stored procedures to fail.
Explanation
A procedure that was called to perform this action failed.
User Action
Run SQL Server Profiler and examine the replmerg.log for failures. If you are using Web Synchronization, elevate
the severity of the websync log, rerun the scenario, and check for errors in the websync.log file.
If you are using Web Synchronization, you can start Replmerg.exe and pass the -T 106 option to use trace flag 106.
This enables you to see the messages that are sent to and from the Publisher. By adding the trace flag to the
Replmerg.exe agent command prompt, the agent writes the client's input messages to a file that is named
ExchangeID(guid).IN.XML, and writes the output messages to a file that is named ExchangeID(guid).OUT.XML. (In
these file names, guid is the GUID of the Exchange Server session.) These files are created in the directory from
which Replmerg.exe was invoked. For security, you should delete these files after you are finished.
Internal-Only
Warehouse
Message Details
Event ID -2147199429
Symbolic Name
Message Text The Merge Agent failed to locate the partitioned snapshot for
this subscription in the expected location. If the publication
does not support Subscriber-requested snapshot generation,
ensure that the partitioned snapshot for this subscription has
been generated.
Explanation
A dynamic snapshot location was specified, but the location does not have any snapshot files.
User Action
Verify that the snapshot location has snapshot files for the specific publication, partition, and time stamp.
Internal-Only
Warehouse
Message Details
Event ID -2147199431
Symbolic Name
Message Text The Merge Agent was unable to generate a partitioned

snapshot for this subscription; either the Snapshot Agent
failed to run or the location for the partitioned snapshot could
not be accessed. The subscription will be initialized using a
standard snapshot.
Explanation
This error indicates one of the following problems occurred:
A failure while running a snapshot job through the snapshot control.
A failure while obtaining the location for the dynamic snapshot job.
User Action
Review the snapshot history tables on the distribution database, or use SQL Server Profiler to debug the snapshot
process.
Internal-Only
Warehouse
Message Details
Event ID -2147199464
Symbolic Name
Message Text The replication Merge Agent failed to propagate a Publisher

schema change to the Subscriber. When troubleshooting,
restart the agent with a higher value for -HistoryVerboseLevel
and check the output log file for errors. Correct any database
engine conditions that may be causing internal replication
stored procedures to fail.
Explanation
User Action
Run SQL Server Profiler and examine replmerg.log for failures. If you are using Web Synchronization, elevate the
severity of the websync log, rerun the scenario, and check for errors in the websync.log file.
Replmerg.exe agent command line, the agent writes the client's input messages to a file that is named
Internal-Only
Warehouse
Message Details
Event ID -2147199466
Symbolic Name
Message Text The merge process could not perform retention-based

metadata cleanup in database '%1'. If this failure continues, try
increasing the query timeout for this process, or try reducing
the retention period. When troubleshooting, restart the
synchronization with verbose history logging and specify an
output file to which to write.
Explanation
User Action
Internal-Only
Warehouse
Message Details
Event ID -2147200928
Symbolic Name
Message Text The version of SQL Server running at the Subscriber is

incompatible with the publication. Either upgrade the
Subscriber to '%1' or change the publication compatibility level
of the publication to match the version of SQL Server currently
running at the Subscriber.
Explanation
The Publisher of the specified publication has a publication compatibility level higher than the current Subscriber.
User Action
Either upgrade the Subscriber or re-create the publication with a compatibility level that matches the current
version of the Subscriber.
Internal-Only
Warehouse
Message Details
Event ID -2147200940
Symbolic Name
Message Text The schema at the Publisher (version: %2!d! and guid: '%1')
does not match the schema at the Subscriber (version: %4!d!
and guid: '%3'). This can occur after the Publisher has been
restored from a backup. In this case, recreate the initial
snapshot and reinitialize all subscriptions.
Explanation
The schema at the Publisher does not match the schema at the Subscriber.
User Action
Re-create the initial snapshot and reinitialize all subscriptions.
Internal-Only
Warehouse
Message Details
Event ID -2147200941
Symbolic Name
Message Text The merge process detected a mismatch while evaluating the
subscriber partition validation expression. The problem can be
resolved by reinitializing the subscription.
Explanation
The merge process detected a mismatch while it was evaluating the Subscriber partition validation expression.
User Action
Reinitialize the subscription.
Internal-Only
Warehouse
Message Details
Event ID -2147200950
Symbolic Name
Message Text The checksum function used by the merge process to perform
data validation on article '%1' returned an invalid checksum
value. When troubleshooting, use SQL Profiler or restart the
agent with a higher value for -HistoryVerboseLevel and check
the output log file for errors. Correct any database engine
conditions that may be causing the checksum operation to fail.
Explanation
A stored procedure returned a NULL or 0 value for the checksum. This could have been caused by a server error.
User Action
Look for other errors raised by the server. Correct any Database Engine conditions that might cause the checksum
operation to fail.
Internal-Only
Warehouse
Message Details
Event ID -2147200953
Symbolic Name
Message Text The merge process was unable to perform data validation on
article '%1'. Check for SQL Server errors in the Windows
application event log or retry at a later time.
Explanation
A stored procedure call to validate the specified article failed. This could have been caused by one or more errors
from the Database Engine.
User Action
Retry the merge operation when SQL Server is less busy. Also, look for any server errors that are raised.
Internal-Only
Warehouse
Message Details
Event ID -2147200968
Symbolic Name
Message Text The merge process failed when obtaining a new identity range
for the subscriber, or failed to determine if the subscriber
needs a new identity range. Restart the synchronization to
obtain the new identity range.
Explanation
This error could indicate that the Publisher's identity range is not large enough.
User Action
Rerun the merge operation to obtain a new range.
Internal-Only
Warehouse
Message Details
Event ID -2147200980
Symbolic Name
Message Text The subscription has expired. Mark the subscription for
reinitialization and restart the Merge Agent to reinitialize the
subscription.
Explanation
This error occurred because an anonymous subscription has expired.
User Action
Reinitialize the anonymous subscription by using sp_reinitmergepullsubscription, and then rerun the merge
operation.
Internal-Only
Warehouse
Message Details
Event ID -2147200989
Symbolic Name
Message Text The merge process could not replicate one or more UPDATE
statements to the '%1' because a stored procedure failed to
execute. Troubleshoot by using SQL Profiler.
Explanation
This error is raised because a failure occurred while updating a row at the destination. There should be additional
server errors that provide more information about the failure. The Merge Agent calls the update procedure for the
article to insert rows on the destination. You can find the name of the update procedure in the update_proc column
of sysmergearticles table.
User Action
Internal-Only
Warehouse
Message Details
Event ID -2147200990
Symbolic Name
Message Text The merge process could not replicate one or more INSERT
statements to the '%1'. A stored procedure failed to execute.
Troubleshoot by using SQL Profiler.
Explanation
This error is raised because a failure occurred while inserting a row at the destination. There should be additional
server errors that provide more information about the failure. The Merge Agent calls the insert procedure for the
article to insert rows on the destination. You can find the name of the insert procedure in the insert_proc column of
sysmergearticles table.
User Action
Internal-Only
Warehouse
Message Details
Event ID -2147201001
Symbolic Name
Message Text The merge process was unable to deliver the snapshot to the
Subscriber. If using Web synchronization, the merge process
may have been unable to create or write to the message file.
When troubleshooting, restart the synchronization with
verbose history logging and specify an output file to which to
write.
Explanation
COM object initialization failed for an XML Subscriber. Some reasons why merge replication did not apply schema
changes to the Subscriber include the following:
A failure to create a directory to write the temporary snapshot files.
A failure to enumerate schema articles.
For SQL Server Compact Subscribers, a failure to reinitialize the subscription.
If the object is message based, a failure to write to the message file.
User Action
Internal-Only
Warehouse
Message Details
Event ID -2147201005
Symbolic Name
Message Text The merge process could not update the last sent generation
sent to the Publisher. If this failure persists, reinitialize the
subscription.
Explanation
The merge operation calls a stored procedure on the Subscriber to find the highest generation that it last sent to
the Publisher and vice versa. The stored procedure call to set the last sent generation failed.
User Action
Internal-Only
Warehouse
Message Details
Event ID -2147201007
Symbolic Name
Message Text The merge process could not update the last generation
received from the Publisher. If this failure persists, reinitialize
the subscription.
Explanation
The merge operation calls a stored procedure on the Subscriber to set the highest generation that it received from
the Publisher and vice versa. The stored procedure call to set the last received generation failed.
User Action
Internal-Only
Warehouse
Message Details
Event ID -2147201021
Symbolic Name
Message Text Publication '%1' is inactive. To activate this publication, start

the Snapshot Agent to generate the initial snapshot.
Explanation
The specified publication is in an inactive state.
User Action
To activate the publication, run the Snapshot Agent of the publication.
Internal-Only
Replication Language Reference
Warehouse
Replication Language Reference contains the following sections.
Replication Views (Transact-SQL)
Replication Tables (Transact-SQL)
Replication Stored Procedures (Transact-SQL)
Warehouse
Replication includes tutorials that you can use to learn how to set up and run replication topologies using SQL
Server Management Studio.
In the replication tutorials, "Publisher" refers to the server that contains that source data being replicated and
"Subscriber" refers to the destination server. The Publisher and Subscriber may share the same instance of SQL
Server, but it is not a requirement. For more information, see Replication Publishing Model Overview.
NOTE
Most of the tasks shown in these tutorials can be performed programmatically. For more information, see Replication
Developer Documentation.
Preparing the Server for Replication
Learn how to prepare servers so that replication can be run with least privileges. You must complete this tutorial
before the other replication tutorials.
Replicating Data Between Continuously Connected Servers
Learn how to use transactional replication to replicate data between fully connected servers.
Replicating Data with Mobile Clients
Learn how to use merge replication to exchange data between a server and one or more clients that are only
occasionally connected.
See Also
Tutorial: Preparing the Server for Replication
Warehouse
It is important to plan for security before you configure your replication topology. This tutorial shows you how to
better secure a replication topology as well as how to configure distribution, which is the first step in replicating
data. You must complete this tutorial before any of the others.
NOTE
To replicate data securely between servers, you should implement all of the recommendations in Replication Security Best
Practices.
What You Will Learn

In this tutorial you will learn how to prepare a server so that replication can run securely with least privileges. The
first lesson shows how to create the Windows service accounts used to run replication agents. The second lesson
shows how to configure the folder used to generate and store publication snapshots. The third lesson shows how
to configure distribution and set permissions.
Requirements
This tutorial is intended for users familiar with fundamental database operations, but who have limited exposure
to replication.
To use this tutorial, your system must have the following components installed:
SQL Server Database Engine with the AdventureWorks2012 database.
Estimated time to complete this tutorial: 30 minutes.
Lessons in This Tutorial

Start the Tutorial
See Also
Warehouse
In this lesson, you will create Windows accounts to run replication agents. You will create a separate Windows
account on the local server for the following agents:
AGENT LOCATION ACCOUNT NAME
Snapshot Agent Publisher <machine_name>\repl_snapshot
Log Reader Agent Publisher <machine_name>\repl_logreader
Distribution Agent Publisher and Subscriber <machine_name>\repl_distribution
Merge Agent Publisher and Subscriber <machine_name>\repl_merge
NOTE
In the replication tutorials, the Publisher and Distributor share the same instance of SQL Server. The Publisher and Subscriber
may share the same instance of SQL Server, but it is not a requirement. If the Publisher and Subscriber share the same
instance, the steps that are used to create accounts at the Subscriber are not required.
To create local Windows accounts for replication agents at the Publisher

1. At the Publisher, open Computer Management from Administrative Tools in Control Panel.
2. In System Tools, expand Local Users and Groups.
3. Right-click Users and then click New User.
4. Enter repl_snapshot in the User name box, provide the password and other relevant information, and then
click Create to create the repl_snapshot account.
5. Repeat the previous step to create the repl_logreader, repl_distribution, and repl_merge accounts.
6. Click Close.
To create local Windows accounts for replication agents at the Subscriber
1. At the Subscriber, open Computer Management from Administrative Tools in Control Panel.
2. In System Tools, expand Local Users and Groups.
3. Right-click Users and then click New User.
4. Enter repl_distribution in the User name box, provide the password and other relevant information, and
then click Create to create the repl_distribution account.
5. Repeat the previous step to create the repl_merge account.
6. Click Close.
Next Steps
You have successfully created Windows accounts for replication agents. Next, you will configure the snapshot
folder. See Lesson 2: Preparing the Snapshot Folder.
See Also
Warehouse
In this lesson, you will learn to configure the snapshot folder that is used to create and store the publication
snapshot.
To create a share for the snapshot folder and assign permissions
1. In Windows Explorer, navigate to the SQL Server data folder. The default location is C:\Program
Files\Microsoft SQL Server\MSSQL.X\MSSQL\Data.
2. Create a new folder named repldata.
3. Right-click this folder and click Properties.
4. On the Sharing tab in the repldata Properties dialog box, click Share.
5. In the File Sharing dialog box, click Share, and then click Done.
6. On the Security tab, click Edit.
7. In the Permissions dialog box, click Add. In the Select User, Computers, Service Account, or Groups
text box, type the name of the Snapshot Agent account created in Lesson 1, as
<Machine_Name>\repl_snapshot, where <Machine_Name> is the name of the Publisher. Click Check
Names, and then click OK.
8. Repeat the previous step to add permissions for the Distribution Agent, as
<Machine_Name>\repl_distribution, and for the Merge Agent as <Machine_Name>\repl_merge.
9. Verify the following permissions are allowed:
repl_snapshot - Full Control
repl_distribution - Read
repl_merge - Read
10. Click OK to close the repldata Properties dialog box and create the repldata share.
Next Steps
You have successfully configured the share for the snapshot folder. Next, you will configure distribution. See
Lesson 3: Configuring Distribution.
See Also
Warehouse
In this lesson, you will configure distribution at the Publisher and set the required permissions on the publication
and distribution databases. If you have already configured the Distributor, you must first disable publishing and
distribution before you begin this lesson. Do not do this if you must retain an existing replication topology.
Configuring a Publisher with a remote Distributor is outside the scope of this tutorial.
Configuring distribution at the Publisher
2. Right-click the Replication folder and click Configure Distribution.
NOTE
If you have connected to SQL Server using localhost rather than the actual server name you will be prompted with a
warning that SQL Server is unable to connect to server 'localhost'. Click OK on the warning dialog. In the Connect
to Server dialog change the Server name from localhost to the name of your server. Click Connect.
The Distribution Configuration Wizard launches.

3. On the Distributor page, select 'ServerName' will act as its own Distributor; SQL Server will create a
distribution database and log, and then click **Next.
4. If the SQL Server is not running, on the SQL ServerAgent Start page, select Yes, configure the SQL Server
Agent service to start automatically. Click Next.
5. Enter \\<Machine_Name>\repldata in the Snapshot folder text box, where <Machine_Name> is the
name of the Publisher, and then click Next.
6. Accept the default values on the remaining pages of the wizard.
7. Click Finish to enable distribution.
Setting database permissions at the Publisher
1. In SQL Server Management Studio, expand Security, right-click Logins, and then select New Login.
2. On the General page, click Search, enter <Machine_Name>\repl_snapshot in the Enter the object name
to select box, where <Machine_Name> is the name of the local Publisher server, click Check Names, and
then click OK.
3. On the User Mapping page, in the Users mapped to this login list select both the distribution and
AdventureWorks2012 databases.
In the Database role membership list select the db_owner role for the login for both databases.
4. Click OK to create the login.
5. Repeat steps 1-4 to create a login for the local repl_logreader account. This login must also be mapped to
users that are members of the db_owner fixed database role in the distribution and AdventureWorks
databases.
6. Repeat steps 1-4 to create a login for the local repl_distribution account. This login must be mapped to a
user that is a member of the db_owner fixed database role in the distribution database.
7. Repeat steps 1-4 to create a login for the local repl_merge account. This login must have user mappings in
the distribution and AdventureWorks databases.
See Also
Tutorial: Replicating Data Between Continuously
Connected Servers
Warehouse
Replication is a good solution to the problem of moving data between continuously connected servers. Using
replication's wizards, you can easily configure and administer a replication topology. This tutorial shows you how
to configure a replication topology for continuously connected servers.
What You Will Learn

This tutorial will show you how to publish data from one database to another using transactional replication. The
first lesson shows how to use SQL Server Management Studio to create a publication. Later lessons show how to
create and validate a subscription and how to measure latency.
Requirements
This tutorial is intended for users who are familiar with basic database operations, but who have limited experience
with replication. This tutorial requires that you have completed the previous tutorial, Preparing the Server for
Replication.
To use this tutorial, your system must have the following components:
At the Publisher server (source):
Any edition of SQL Server, except Express ( SQL Server Express) or SQL Server Compact. These
editions cannot be replication Publishers.
AdventureWorks2012 sample database. To enhance security, the sample databases are not installed
by default.
Subscriber server (destination):
Any edition of SQL Server, except SQL Server Compact. SQL Server Compact cannot be a Subscriber in
NOTE
Replication is not installed on SQL Server Express by default.
NOTE
In SQL Server Management Studio, you must connect to the Publisher and Subscriber using a login that is a member of the
sysadmin fixed server role.

Lesson 1: Publishing Data Using Transactional Replication
Lesson 2: Creating a Subscription to the Transactional Publication
Lesson 3: Validating the Subscription and Measuring Latency
Start the Tutorial
See Also
Lesson 1: Publishing Data Using Transactional
Replication
Warehouse
In this lesson, you will create a transactional publication using SQL Server Management Studio to publish a filtered
subset of the Product table in the AdventureWorks2012 sample database. You will also add the SQL Server
login used by the Distribution Agent to the publication access list (PAL). Before starting this tutorial, you should
have completed the previous tutorial, Preparing the Server for Replication.
To create a publication and define articles
2. Expand the Replication folder, right-click the Local Publications folder, and click New Publication.
The Publication Configuration Wizard launches.
3. On the Publication Database page, select AdventureWorks2012, and then click Next.
4. On the Publication Type page, select Transactional publication, and then click Next.
5. On the Articles page, expand the Tables node, select the Product check box, then expand Product and
clear the ListPrice and StandardCost check boxes. Click Next.
6. On the Filter Table Rows page, click Add.
7. In the Add Filter dialog box, click the SafetyStockLevel column, click the right arrow to add the column to
the Filter statement WHERE clause of the filter query, and modify the WHERE clause as follows:
WHERE [SafetyStockLevel] < 500
8. Click OK, and then click Next.

9. Select the Create a snapshot immediately and keep the snapshot available to initialize
subscriptions check box, and click Next.
10. On the Agent Security page, clear Use the security settings from the Snapshot Agent check box.
11. Click Security Settings for the Snapshot Agent, enter <Machine_Name>\repl_snapshot in the Process
account box, supply the password for this account, and then click OK.
12. Repeat the previous step to set repl_logreader as the process account for the Log Reader Agent, and then
click Finish.
13. On the Complete the Wizard page, type AdvWorksProductTrans in the Publication name box, and click
Finish.
14. After the publication is created, click Close to complete the wizard.
To view the status of snapshot generation
1. Connect to the Publisher in SQL Server Management Studio, expand the server node, and then expand the
Replication folder.
2. In the Local Publications folder, right-click AdvWorksProductTrans, and then click View Snapshot
Agent Status.
3. The current status of the Snapshot Agent job for the publication is displayed. Verify that the snapshot job
has succeeded before you continue to the next lesson.
To add the Distribution Agent login to the PAL
Replication folder.
2. In the Local Publications folder, right-click AdvWorksProductTrans, and then click Properties.
The Publication Properties dialog box is displayed.
3. Select the Publication Access List page, and click Add.
4. \In the Add Publication Access dialog box, select <Machine_Name>\repl_distribution and click OK.
Click OK.
Next Steps
You have successfully created the transactional publication. Next, you will subscribe to this publication. See Lesson
2: Creating a Subscription to the Transactional Publication.
See Also
Define an Article
Lesson 2: Creating a Subscription to the Transactional
Publication
Warehouse
In this lesson, you will create a subscription using SQL Server Management Studio. This lesson requires that you
have completed the previous lesson, Lesson 1: Publishing Data Using Transactional Replication.
To create the subscription
Replication folder.
2. In the Local Publications folder, right-click the AdvWorksProductTrans publication, and then click New
Subscriptions.
The New Subscription Wizard launches.
3. On the Publication page, select AdvWorksProductTrans, and then click Next.
4. On the Distribution Agent Location page, select Run all agents at the Distributor, and then click Next.
5. On the Subscribers page, if the name of the Subscriber instance is not displayed, click Add Subscriber, click
Add SQL Server Subscriber, enter the Subscriber instance name in the Connect to Server dialog box, and
then click Connect.
6. On the Subscribers page, select the instance name of the Subscriber server, and select under Subscription
Database.
7. On the New Database dialog box, enter ProductReplica in the Database name box, click OK, and then
click Next.
8. In the Distribution Agent Security dialog box, click the ellipsis () button, enter
<Machine_Name>\repl_distribution in the Process account box, enter the password for this account,
click OK, and then click Next.
9. Click Finish to accept the default values on the remaining pages and complete the wizard.
Setting database permissions at the Subscriber
1. Connect to the Subscriber in SQL Server Management Studio, expand Databases, ProductReplica, and
Security, right-click Users, and then select New User.
2. On the General page, in the User type list, select Windows user.
3. Select the User name box and click the ellipsis () button, in the Enter the object name to select box
type <Machine_Name>\repl_distribution, click Check Names, and then click OK.
4. On the Membership page, in Database role membership area, select db_owner, and then click OK to
create the user.
To view the synchronization status of the subscription
Replication folder.
2. In the Local Publications folder, expand the AdvWorksProductTrans publication, right-click the
subscription in the ProductReplica database, and then click View Synchronization Status.
The current synchronization status of the subscription is displayed.
3. If the subscription is not visible under AdvWorksProductTrans, press F5 to refresh the list.
Next Steps
You have successfully created a subscription to the transactional publication. Because the Distribution Agent for
this subscription runs continuously, the subscription is initialized when it is created. Next, you will use tracer tokens
to verify that changes are being replicated to the Subscriber and to determine latency. See Lesson 3: Validating the
Subscription and Measuring Latency.
See Also
Lesson 3: Validating the Subscription and Measuring
Latency
Warehouse
In this lesson, you will use tracer tokens to verify that changes are being replicated to the Subscriber and to
determine latency, the time it takes for a change made at the Publisher to appear to the Subscriber. This lesson
requires that you have completed the previous lesson, Lesson 2: Creating a Subscription to the Transactional
Publication.
To insert a tracer token and view information on the token
1. Connect to the Publisher in SQL Server Management Studio, expand the server node, right-click the
Replication folder, and then click Launch Replication Monitor.
Replication Monitor launches.
2. Expand a Publisher group in the left pane, expand the Publisher instance, and then click the
AdvWorksProductTrans publication.
3. Click the Tracer Tokens tab.
4. Click Insert Tracer.
5. View elapsed time for the tracer token in the following columns: Publisher to Distributor, Distributor to
Subscriber, Total Latency. A value of Pending indicates that the token has not reached a given point.
Next Steps
In this lesson, you successfully used tracer tokens to validate that data changes are being replicated from the
Publisher to the Subscriber. You can also insert, update, or delete data in the Product table at the Publisher and
query the Product table at the Subscriber to view these changes after they are replicated.
This completes the Replicating Data Between Continuously Connected Servers tutorial. For a similar tutorial that
uses merge replication, see Tutorial: Replicating Data with Mobile Clients.
See Also
Tutorial: Replicating Data with Mobile Clients
Warehouse
Replication is a good solution to the problem of moving data between a central server and mobile clients that are
only occasionally connected. Using replication's wizards, you can easily configure and administer a replication
topology. This tutorial shows you how to configure a replication topology for mobile clients.
What You Will Learn

In this tutorial you will use merge replication to publish data from a central database to one or more mobile users
so that each user gets a uniquely filtered subset of the data. The first lesson shows how to use SQL Server
Management Studio to create a publication. Later lessons show how to create and synchronize a subscription.
Requirements
This tutorial is intended for users familiar with fundamental database operations, but who have limited experience
with replication. Before you start this tutorial, you must complete Tutorial: Preparing the Server for Replication.
To use this tutorial, your system must have the following components installed:
At the Publisher server (source):
Any edition of SQL Server 2017, except for Express ( SQL Server Express) or SQL Server Compact.
These editions cannot be a replication Publisher.
The AdventureWorks2012 sample database. To enhance security, the sample databases are not
installed by default..
Subscriber server (destination):
Any edition of SQL Server 2017, except for SQL Server Compact. SQL Server Compact is not supported
by the publication created in this tutorial.
NOTE
Replication is not installed by default on SQL Server Express.
NOTE
In SQL Server Management Studio, you must connect to the Publisher and Subscriber using a login that is a member of the
sysadmin fixed server role.

Lesson 2: Creating a Subscription to the Merge Publication
Start the Tutorial
See Also
Warehouse
In this lesson, you will create a merge publication using SQL Server Management Studio to publish a subset of the
Employee, SalesOrderHeader, and SalesOrderDetail tables in the AdventureWorks2012 sample database.
These tables are filtered with parameterized row filters so that each subscription contains a unique partition of the
data. You will also add the SQL Server login used by the Merge Agent to the publication access list (PAL). This
tutorial requires that you have completed the previous tutorial, Preparing the Server for Replication.
To create a publication and define articles
2. Expand the Replication folder, right-click Local Publications, and click New Publication.
The Publication Configuration Wizard launches.
3. On the Publication Database page, select AdventureWorks2012, and then click Next.
4. On the Publication Type page, select Merge publication, and then click Next.
5. On the Subscriber Types page, ensure that only SQL Server 2008 or later is selected, and then click Next.
6. On the Articles page, expand the Tables node, select SalesOrderHeader and SalesOrderDetail, then
expand Employee, select EmployeeID or LoginID, and then click Next.
TIP
Additional required columns are automatically selected. Select any of the automatically selected columns and view
the note below the Objects to publish list for an explanation why the column is required.
7. On the Filter Table Rows page, click Add and then click Add Filter.
8. In the Add Filter dialog box, select Employee (HumanResources) in Select the table to filter, click the
LoginID column, click the right arrow to add the column to the WHERE clause of the filter query, and
modify the WHERE clause as follows:
WHERE [LoginID] = HOST_NAME()
9. Click A row from this table will go to only one subscription, and click OK.
10. On the Filter Table Rows page, click Employee (Human Resources), click Add, and then click Add Join
to Extend the Selected Filter.
11. In the Add Join dialog box, select Sales.SalesOrderHeader under Joined table, click Write the join
statement manually, and complete the join statement as follows:
ON Employee.EmployeeID = SalesOrderHeader.SalesPersonID
12. In Specify join options, select Unique key, and then click OK.
13. On the Filter Table Rows page, click SalesOrderHeader, click Add, and then click Add Join to Extend the
Selected Filter.
14. In the Add Join dialog box, select Sales.SalesOrderDetail under Joined table.
15. Click Write the join statement manually.
16. In Filtered table columns, select BusinessEntityID, then click the arrow button to copy the column name
to the loin statement.
17. In the Join statement box, complete the join statement as follows:
ON Employee.BusinessEntityID = SalesOrderHeader.SalesPersonID
18. In Specify join options, select Unique key, and then click OK.
19. On the Filter Table Rows page, click SalesOrderHeader (Sales), click Add, and then click Add Join to
Extend the Selected Filter.
20. In the Add Join dialog box, select Sales.SalesOrderDetail under Joined table, click OK, and then click
Next.
21. Select Create a snapshot immediately, clear Schedule the snapshot agent to run at the following
times, and click Next.
22. On the Agent Security page, click Security Settings, type <Machine_Name>\repl_snapshot in the
Process account box, supply the password for this account, and then click OK. Click Finish.
23. On the Complete the Wizard page, enter AdvWorksSalesOrdersMerge in the Publication name box and
click Finish.
24. After the publication is created, click Close.
To view the status of snapshot generation
Replication folder.
2. In the Local Publications folder, right-click AdvWorksSalesOrdersMerge, and then click View Snapshot
Agent Status.
3. The current status of the Snapshot Agent job for the publication is displayed. Ensure that the snapshot job
has succeeded before you continue to the next lesson.
To add the Merge Agent login to the PAL
Replication folder.
2. In the Local Publications folder, right-click AdvWorksSalesOrdersMerge, and then click Properties.
3. Select the Publication Access List page, and click Add.
4. In the Add Publication Access dialog box, select <Machine_Name>\repl_merge and click OK. Click OK.
Next Steps
You have successfully created the merge publication. Next, you will subscribe to this publication. See Lesson 2:
Creating a Subscription to the Merge Publication.
See Also
Define an Article
Lesson 2: Creating a Subscription to the Merge
Publication
Warehouse
In this lesson, you will create the subscription using SQL Server Management Studio. You will then set permissions
on the subscription database and manually generate the filtered data snapshot for the new subscription. This
lesson requires that you have completed the previous lesson, Lesson 1: Publishing Data Using Merge Replication.
To create the subscription
1. Connect to the Subscriber in SQL Server Management Studio, expand the server node, expand the
Replication folder, right-click the Local Subscriptions folder, and then click New Subscriptions.
The New Subscription Wizard launches.
2. On the Publication page, click Find SQL Server Publisher in the Publisher list.
3. In the Connect to Server dialog box, enter the name of the Publisher instance in the Server name box, and
click Connect.
4. Click AdvWorksSalesOrdersMerge, and click Next.
5. On the Merge Agent Location page, click Run each agent at its Subscriber, and then click Next.
6. On the Subscribers page, select the instance name of the Subscriber server, and under Subscription
Database, select from the list.
7. In the New Database dialog box, enter SalesOrdersReplica in the Database name box, click OK, and
then click Next.
8. On the Merge Agent Security page, click the ellipsis () button, enter <Machine_Name>\repl_merge in
the Process account box, supply the password for this account, click OK, click Next, and then click Next
again.
9. On the Initialize Subscriptions page, select At first synchronization from the Initialize When list, click
Next, and then click Next again.
10. On the HOST_NAME Values page, enter a value of adventure-works\pamela0 in the HOST_NAME Value
box, and then click Finish.
11. Click Finish again, and after the subscription is created, click Close.
Setting database permissions at the Subscriber
1. Connect to the Subscriber in SQL Server Management Studio, expand Databases, SalesOrdersReplica,
and Security, right-click Users, and then select New User.
2. On the General page, enter <Machine_Name>\repl_merge in the User name box, click the ellipsis ()
button, click Browse, select <Machine_Name>\repl_merge, click OK, click Check Names, and then click
OK.
3. In Database role membership, select db_owner, and then click OK to create the user.
To create the filtered data snapshot for the subscription
Replication folder.
2. In the Local Publications folder, right-click the AdvWorksSalesOrdersMerge publication, and then click
Properties.
3. Select the Data Partitions page, and click Add.
4. In the Add Data Partition dialog box, type adventure-works\pamela0 in the HOST_NAME Value box,
and then click OK.
5. Select the newly added partition, click Generate the selected snapshots now, and then click OK.
Next Steps
You have successfully created a subscription to the merge publication and generated the filtered snapshot for the
new subscription's data partition so that it will be available when the subscription is initialized. Next, you will grant
rights to the Merge Agent on the subscription database and run the Merge Agent to start synchronization and
initialize the subscription. See Lesson 3: Synchronizing the Subscription to the Merge Publication.
See Also
Lesson 3: Synchronizing the Subscription to the
Merge Publication
Warehouse
In this lesson, you will start the Merge Agent to initialize the subscription using SQL Server Management Studio.
You also use this procedure to synchronize with the Publisher. This lesson requires that you have completed the
previous lesson, Lesson 2: Creating a Subscription to the Merge Publication.
To start synchronization and initialize the subscription
1. Connect to the Subscriber in SQL Server Management Studio, expand the server node, and then expand the
Replication folder.
2. In the Local Subscriptions folder, right-click the subscription in the SalesOrdersReplica database, and
then click View Synchronization Status.
3. Click Start to initialize the subscription.
Next Steps
You have successfully run the Merge Agent to start synchronization and initialize the subscription. You can also
insert, update, or delete data in the SalesOrderHeader or SalesOrderDetail tables at the Publisher or Subscriber,
repeat this procedure when network connectivity is available to synchronize data between the Publisher and the
Subscriber, and then query the SalesOrderHeader or SalesOrderDetail tables at the other server to view the
replicated changes.
This completes the Replicating Data with Mobile Clients tutorial. For a similar tutorial that uses transactional
replication, see Tutorial: Replicating Data Between Continuously Connected Servers.
See Also
Synchronize Data

Replication

Uploaded by

Copyright:

Available Formats

Replication

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Replication

Uploaded by

Copyright:

Available Formats

Table of Contents

Items Deprecated in SQL Server 2016

Breaking Changes Made in SQL Server 2016

2016 OR EARLIER 2017 OR LATER

Replication to Oracle Up to Oracle 12c Not supported

Publishing Data from Oracle

For more information, see Oracle Publishing Overview.

Publishing Data to Non-SQL Server Subscribers

SNAPSHOT REPLICATION AND

Stored Procedures Definition ( X X

Stored Procedures Execution ( X no

Indexed Views as Tables X no

User-Defined Types (CLR) X X

User-Defined Functions ( Transact- X X

Alias Data Types X X

Full text indexes X X

Schema Objects (constraints, indexes, X X

Publishing Stored Procedures

Publishing User-Defined Functions

Publishing User-Defined Types and Alias Data Types

Publishing Full Text Indexes

Making Schema Changes to Published Objects

Considerations for Publishing

Identity range management @auto_identity_range (deprecated) and

Publisher identity range @pub_identity_range

Identity range @identity_range

Identity range threshold @threshold

For more information about these parameters, see sp_addarticle (Transact-SQL).

PROPERTY PARAMETER IN SP_ADDMERGEARTICLE

Column tracking @column_tracking

Schema options @schema_option

Column filtering @vertical_partition

Subscriber upload options @subscriber_upload_options

Conditional delete tracking @delete_tracking

Error compensation @compensate_for_errors

Identity range management @auto_identity_range (deprecated) and

Publisher identity range @pub_identity_range

Identity range @identity_range

Identity range threshold @threshold

Partition options @partition_options

Blob column streaming @stream_blob_columns

Filter type @filter_type (parameter in sp_addmergefilter)

Interoperability of Replication and High Availability Features

How Snapshot Replication Works

Distribution Agent and Merge Agent

How Transactional Replication Works

Concurrent Snapshot Processing

Modifying Data and the Log Reader Agent

Two configurations are required

Remarks and Restrictions

Modifying a schema file

Replicated table must have a primary key.

Only push subscriptions to SQL Database are supported.

Only @subscriber_type = 0 is supported in sp_addsubscription for SQL Database.

Replication supports the republishing scenarios shown in the following table.

PUBLISHER PUBLISHING SUBSCRIBER SUBSCRIBER

Transactional publication Transactional subscription/transactional Transactional subscription

Transactional publication Transactional subscription/merge Merge subscription

Merge publication Merge subscription/merge publication Merge subscription