SQL Server version 7.0 Service Pack 4 (SP4) is the earliest version that can participate in a replication topology with SQL Server 2005. If you use SQL Server 2000, SP3 or later is required.

When you replicate between or among different versions of SQL Server, you are often limited to the functionality of the earliest version used. For example, if you upgrade a Distributor to an instance of SQL Server 2005, but you have a Publisher running an instance of SQL Server 2000, and a Subscriber running an instance of SQL Server 7.0, you are limited to the general functionality and replication functionality of SQL Server 7.0.

For all types of replication, the Distributor version must be no earlier than the Publisher version (in many cases the Distributor is the same instance as the Publisher). You can use SQL Server 2005 as a remote Distributor for SQL Server 2005 and SQL Server 2000, but not for SQL Server 7.0. The following tables provide additional information about which versions of SQL Server can participate in the same topology. For more information about replication features supported in the various editions of SQL Server, see Features Supported by the Editions of SQL Server 2005.

Transactional Replication and Snapshot Replication with Read-Only Subscribers

The above table shows that a read-only Subscriber to a transactional publication can be any version within two versions of the Publisher version. For example, a SQL Server 7.0 Publisher can have SQL Server 2005 Subscribers, and a SQL Server 2005 Publisher can have SQL Server 7.0 Subscribers.

Transactional Replication with Updating Subscribers

¹ For a SQL Server 7.0 Publisher, only SQL Server 7.0 Subscribers are supported.

² For a SQL Server 2000 Publisher, SQL Server 7.0, SQL Server 2000, and SQL Server 2005 Subscribers are supported.

³ For a SQL Server 2005 Publisher, SQL Server 2000 and SQL Server 2005 Subscribers are supported.

Merge Replication

The above table shows that a Subscriber to a merge publication can be any version no later than the Publisher version. For more information about compatibility for previous versions, see "Compatibility Level for Merge Publications" later in this topic.

SQL Server 2005 has introduced a number of new data types. These new data types are mapped to compatible data types at the Subscriber if push subscriptions from a SQL Server 2005 Distributor are used.

SQL Server 2005 data type	SQL Server 2000 or SQL Server 7.0 data type
XML	NTEXT
CLR User Defined Types (UDT)	IMAGE
VARCHAR(max)	TEXT
NVARCHAR(max)	NTEXT
VARBINARY(max)	IMAGE

You must verify that VARCHAR(max), NVARCHAR(max), VARBINARY(max), XML, and CLR UDT types are mapped appropriately if they are replicated to Subscribers running earlier versions of SQL Server (this is done by default for articles in merge publications). Mapping behavior for these types is controlled by the schema options 0x20, 0x10000000, and 0x20000000 for sp_addarticle (Transact-SQL) and sp_addmergearticle (Transact-SQL). For more information about setting schema options, see How to: Specify Schema Options (SQL Server Management Studio) and How to: Specify Schema Options (Replication Transact-SQL Programming).

SQL Server 2000 introduced two data types that are mapped to compatible data types for SQL Server 7.0. These new data types are mapped to compatible data types at the Subscriber if push subscriptions from a SQL Server 2005 or SQL Server 2000 Distributor are used.

SQL Server 2005 or SQL Server 2000 data type	SQL Server 7.0 data type
SQL_VARIANT	IMAGE
BIGINT	DECIMAL

You can retain replication settings when restoring a backup of a replicated database from a previous version. If you restore the backups to a server and database with the same names as the server and database at which the backup was taken, or if you specify the KEEP_REPLICATION option, replication settings are preserved. For more information, see RESTORE (Transact-SQL). After restoring the database, execute sp_vupgrade_replication (Transact-SQL) to upgrade schema and system data to support replication at the current product level.

Although preserving replication after restoring from backup from previous version is possible, it is rarely used as an upgrade option. It is more common to upgrade the replicated database as part of a product upgrade or to re-create the database and replication configuration from a set of scripts.

Merge replication uses the publication compatibility level to determine which features can be used by publications in a given database. The values range from 70RTM (SQL Server 7.0 with no service packs installed) to 90RTM. The compatibility level is specified:

• With the @publication_compatibility_level parameter of sp_addmergepublication (Transact-SQL). For more information, see How to: Set the Publication Compatibility Level (Replication Transact-SQL Programming).
  
• On the Subscriber Types page of the New Publication Wizard. For more information about running this wizard, see How to: Create a Publication and Define Articles (SQL Server Management Studio).
  
• On the General page of the Publication Properties - <Publication> dialog box. For more information, see How to: Set the Publication Compatibility Level (SQL Server Management Studio).
  

The following features require a compatibility level of 90RTM or higher:

• Logical records. For more information, see Grouping Changes to Related Rows with Logical Records.
  
• Subscriber upload options. For more information, see Optimizing Merge Replication Synchronization Performance with Download-Only Articles.
  
• Nonoverlapping partitions. For more information, see Parameterized Row Filters.
  
• Business logic handlers. For more information, see Executing Business Logic During Merge Synchronization.
  
• Schema changes using ALTER <OBJECT> statements. For more information, see Schema Changes on Publication Databases.
  

The following features do not depend on the compatibility level, but they do require the Merge Agent that ships with SQL Server 2005; Subscribers running previous versions of SQL Server function as though the feature is not enabled:

• Precomputed partitions. For more information, see Optimizing Parameterized Filter Performance with Precomputed Partitions.
  
• Web synchronization. For more information, see Web Synchronization for Merge Replication.
  
• Parallel phase agents (specifying -ParallelUploadDownload for the Merge Agent). For more information, see Replication Merge Agent.
  
• New snapshot features for publications that use parameterized filters, which include the ability:
  
  • For a Subscriber to request a snapshot if one is not available for its partition.
    
  • For an administrator to pre-generate and schedule generation of snapshots.
    
  • To deliver parameterized snapshots using FTP.
    
  For more information, see Snapshots for Merge Publications with Parameterized Filters and Transferring Snapshots Through FTP.
  
• Improved history logging and article-level statistics in Replication Monitor. For more information, see How to: View Information and Perform Tasks for a Subscription (Replication Monitor).