Here are answers to some frequently asked questions about replication.
Only SQL Server 6.0 servers can participate in replication. SQL Server 6.0 servers can publish, distribute, and subscribe to replicated data. However, replication is designed to supportžin the futurežother types of ODBC-enabled subscribers.
Not replicated are system tables and changes to the schema of a published table.
When the identity property has been applied to a column, data from that column can be replicated, but the identity property cannot. The identity property will not be applied to that column on subscription servers. For information about the identity property, see the Microsoft SQL Server Transact-SQL Reference.
All datatypes are replicated, with these exceptions:
Note Text and image columns can be replicated via the table refresh mechanism. See "How are text and image columns handled?" next in this chapter.
Also, when setting up a publication, you can choose to pass user-defined datatypes or convert them to their base datatypes.
Transaction-based replication of text and image columns is not supported. However, scheduled table refresh of text and image columns is supported.
For example, you could publish an article that contains text and image columns and do a table refresh of the subscribers at a defined interval (for example, every hour). You could then join the text and image destination table with a transaction log-based destination table. To ensure proper consistency, you would probably need to publish a timestamp column.
For information about publishing a table by using the Scheduled Table Refresh option, see Chapter 14, Setting Up Replication.
SQL Server replication permits each subscription server to subscribe only once to a particular article. Note that if a subscriber subscribes at the publication level, it is automatically subscribed to each article in that publication.
However, it is possible for a subscription server to use multiple copies of replicated data, since secondary copies of data can be locally processed on the subscription server.
For example, if database_1 subscribes to table_a, then database_2 on the same server cannot subscribe to the same article. However, you could, for example, create a trigger on the destination table_a in database_1 that does an insert, update, or delete into a table in database_2 every time destination table_a is updated. Or you could create a cross-database view using the replicated data.
In most cases, data will be modified only on the publication server. It is recommended that you maintain all replicated data residing in destination tables on subscription servers as read-only. (This means the data should be treated as read-only for the users of the subscription databases. Do not set the Read Only database option, or that subscription database will be unable to receive replicated data.)
This is not as limiting as it might at first sound, since each server can act as both subscriber and publisher and since secondary copies of data can be locally processed on the subscriber. For examples of publishing subscribers and of secondary processing of data, see Chapter 15, Advanced Replication.
Yes. It possible to have one server distributing from a number of publication servers to a number of subscription servers. However, this increases the hardware requirements for the distribution server. In such a configuration, the distribution server will require additional memory and available disk space. A multiprocessor machine would be beneficial in this environment because it would take full advantage of the multithreaded architecture of the replication processes.
The replication capability of SQL Server 6.0 is not specifically designed to accomplish hot backups, and it does not allow the subscriber to be automatically updated on changes that affect system tables (such as schema changes or permission changes).