When adding an article to a publication that has active subscriptions, you can filter the article using a subset filter clause without requiring that subscriptions be reinitialized. The Merge Agent will then synchronize any data changes for the subscription. If the publication already has subscriptions, Subscribers will receive the schema and data for the new article based on this snapshot the next time they synchronize. When adding an article to a merge publication for which there are active subscriptions, you must run the Snapshot Agent after adding the article before any Subscribers can synchronize. When you add articles to a merge publication, a reinitialization of existing subscriptions is not required for the new article schema and data to be propagated to Subscribers. Specify a default value for the column.When defining the new column through the replication user interface or through replication stored procedures, you must do one of the following: To avoid reinitializing subscriptions, add the column to the published article immediately, instead of waiting to add it to an existing article. However, if you add the column to a publication later, subscriptions to the publication will need to be reinitialized for all types of publications. When you add a column to the publishing table, but do not include the column in a publication, no further action is required. The Distribution Agent re-executes the ALTER TABLE statement if the destination table is not republished at the Subscriber, otherwise, it re-executes the sp_repladdcolumn or sp_repldropcolumn, including all the original syntax, at each affected Subscriber at the time of the next synchronization. This is because the Merge Agent re-executes the sp_repladdcolumn stored procedure (or sp_repldropcolumn for the dropping of a column), including all of its original syntax, at each affected Subscriber at the time of the next synchronization. When creating a new column and immediately adding it to a published article, a reinitialization is not required. Reinitialization of the subscription is necessary only when you add an existing column to a published article. Whenever you add a column to a transactional publication, the appropriate ALTER TABLE statement (or sp_repladdcolumn or sp_repldropcolumn if the table is republished at the Subscriber) will be propagated and run at the Subscribers to complete the schema changes at the subscription databases. To a published article, using a column that exists in an underlying table.This option also lets you defer inclusion of a new column in a published article until a later date. For example, if you want to add a column that includes sensitive or proprietary data, this choice allows you to make a schema change without propagating the information to Subscribers.
You may want to make a schema change to the underlying table but not to the published article. To the underlying table, without including it in the published article.Here, you add a column and apply the schema change immediately to one or more existing publications the change is propagated to the Subscribers of those publications. To an article in one or more publications.This will ensure that you can recover the publication database in its correct state if there is a failure of the Publisher. It is recommended that you back up the publication database after making schema changes or using sp_mergecleanupmetadata. Changes made to the schema of a published table using these tools will not be propagated to Subscribers. Do not make schema changes to published tables using the SQL ALTER TABLE statements in a tool such as SQL Query Analyzer or by using SQL Server Enterprise Manager visual database tools. Important Schema changes to a published table must be made only through the replication publication properties dialog box in SQL Server Enterprise Manager or through replication stored procedures. For transactional replication and merge replication, the schema change is propagated incrementally when the Distribution Agent or Merge Agent runs. For snapshot replication, the schema change is propagated when a new snapshot is reapplied at the Subscriber.
Column additions and deletions are implemented at the table level and propagated to all Subscribers that receive data from that table. Schema changes can be replicated during snapshot replication, transactional replication, and merge replication. You can add columns to, and drop columns from, a published table without dropping and recreating the publications and subscriptions referencing that table. Microsoft® SQL Server™ 2000 supports common schema changes to an existing publication database. Check out Books online, YOur friendly resource.