Q. When is the MSreplication_subscriptions table created on the subscriber?
A. The Distribution agent creates the MSreplication_subscriptions table at start up if it does not already exist. In addition, the sp_addpullsubscription stored procedure also creates the MSreplication_subscriptions table if it does not already exist at the subscriber.
Q. What .exe or .dll file is called for each agent?
A. The following table shows the agent names and associated files:
Collapse this tableExpand this table
NOTE: The Distribution and Merge agents can also be invoked through the Sqldistx.dll and Sqlmergx.dll ActiveX interfaces.
Q. Would I need multiple distribution databases?
A. In most cases, you only need one. This feature is for people who are centralizing replication operations and administration, and want one distribution server to host many publishers. You can support many publishers to one distribution database, but there may be cases where you want to separate logical replication applications into separate databases, for administration purposes. In some cases, there may also be a performance benefit because you may have reduced contention (both writing to and reading from the distribution database).
Q. Can all servers in a merge setup have the same priority?
A. The publisher and subscriber can never have the same priority; SQL Server enforces this while adding subscriptions. However, if there are two subscriptions (for example, S1 and S2) that have the same priority, the first subscription that gets the changes to the publisher succeeds. That is, if S1 and S2 made changes in a pseudo-simultaneous fashion, the first one to merge changes with the publisher succeeds. The same rule also applies to local subscriptions, which essentially have a priority of 0 (the first one to the hub succeeds).
Q. Synchronizing on Internet publications fails with the error "Couldn't deliver schema information." Why?
A. It is possible that the File Copy operations failed. By default, pull agents use the Universal Naming Convention (UNC) path set for the distributor/publisher to open the files. If the computer is not on the Local Area Network (LAN), UNC will not work. You can set up FTP server at the distributor and set the Merge agent command line to include an FTP address. Publications enabled for the Internet will have the initial snapshot downloaded to the client computer by the Merge agent through FTP before it is applied to the subscriber. For more information, refer to SQL Server Books Online.
Q. Is it possible to do a merge replication from SQL Server 7.0 to a Microsoft Access 97 database?
A. Merge replication to Access 97 databases will be supported only with the next version of Access. The other piece required for this functionality to work is the JET Replication Provider, which will be included in SQL Server 7.0 and the next version of Microsoft Office.
Q. Is it possible to pull a merge publication from an Access 97 database using the replication ActiveX control?
A. You will be able to use the ActiveX control to merge a pull subscription from an Access .mdb file to the SQL Server 7.0 merge publication. For sample code that demonstrates this ability, refer to SQL Server Books Online.
Q. Is it possible to do a merge replication from SQL Server 7.0 to ODBC subscribers?
A. You can push a snapshot to heterogeneous ODBC subscribers, but not merge publications.
Q. Is it possible to pull a merge publication from any ODBC subscriber from SQL Server 7.0 using the replication ActiveX control?
A. No. Merge replication is only supported with SQL Server 7.0 and Jet 4.0.
Q. What is happening to "Restricted" publications?
A. Restricted publications, as implemented in SQL Server 6.5, are no longer supported. However, SQL Server 7.0 has an even better capability: the Publication Access List (PAL). With a PAL, you can specify Windows NT groups or standard logins that can subscribe to a specific publication. For more information, see the "Publication Access List" topic in SQL Server Books Online.
Q. I used the Uninstall Publishing And Distribution Wizard, and the physical files for the distribution database persisted on my hard disk. Is this by design? When I reinstall replication, what will happen?
A. When removing distribution, SQL Server attempts to remove the physical files. However, if the distribution database is used by other clients or if there is a sharing violation when the file is being deleted, the file will not actually be removed from the hard disk. If the physical file was not removed and you try to install distribution again, a new name will be used for the distribution database.
Q. If I create a snapshot publication with one table in an article, and then change the schema of the published table (for example, by adding a column to the table), will the new schema ever be applied at the subscribers?
A. Changes to a published table's schema are not replicated in SQL Server 7.0. If you want to replicate the new column, you must create a new publication and subscribe to it.
Q. What is a good way to see what the command in MSRepl_Commands says?
A. In the distribution database, execute the sp_browsereplcmds stored procedure.
Q. What if the Snapshot agent has not completed when Distribution agent starts?
A. It is not a problem if the Distribution agent runs at the same time as the Snapshot agent. If the Distribution agent runs and there is not a snapshot available, it will wait (if continuous) or shut down with a message stating that a snapshot is not yet available.
Q. On Windows NT Server, the Transactional Replication feature is unavailable. Why?
A. This feature is unavailable when you are running the Desktop Edition of SQL Server. Note that the Desktop Edition can be installed on any platform.
Q. Checksum validation fails after using an ALTER TABLE statement, even after a resynchronization. Why?
A. For Checksum() to work correctly, the two tables must have exactly the same binary structure on the page, which is not the case if you do an ALTER TABLE at the publisher and a create table at the subscriber.
Q. Using updating subscribers, the published table is altered. Why?
A. Tables participating in publications or subscriptions will be required to have a SQL Server timestamp column. If one does not exist, SQL Server 7.0 will automatically add one when you create the publication. If you stop publishing a table, it is easy to simply drop the timestamp column. Applications will work unchanged against tables with the timestamp column because it is not necessary to include this column in qualified INSERT, UPDATE, or DELETE statements.
Q. Will Host Data Replicator (HDR) work on SQL Server 7.0?
A. No. HDR is supported only with SQL Server 6.5. If you want to use SQL Server 7.0, use Data Transformation Services (DTS) instead.
Didn't see an answer to your question? Check out the Microsoft SQL Server newsgroups at the following Microsoft Web site:
Microsoft technical communities provide opportunities to interact with Microsoft employees, experts, and your peers in order to share knowledge and news about Microsoft products and related technologies. These technical communities provide a variety of ways to access answers to questions, to access solutions to problems, and to share your own expertise. These technical communities are located at the following Microsoft Web site: