I have deployed 1 subscriber and 1 publisher server in merge replication configuration of SQL Server. I added a table along with a trigger on that table on publisher and want to replicate that table and trigger on subscriber. I have set 'replicate schema changes' and 'copy user triggers' to true but still the trigger is not replicated on subscriber.
How can I solve the problem?
I had a similar problem with merge replication. Despite anything I tried, new schema changes at Publisher were not applied at Subscriber even with Replicate schema changes set to true. In my case it were new columns not propagated to Subscriber even though they were explicitly checked at Publisher to be replicated, instead the following error was returned during sync:
Invalid column name 'new_col_name'. (Source: MSSQLServer, Error number: 207)
I ended up removing merge subscription, adding the new columns at Subscriber and then recreating the subscription. The same may be done to triggers.
Note, after removing and recreating Subscription you may need to re-initialize it which will replace all data in Subscriber's articles. If you want to preserve existing subscriber objects/data make sure to set the article property Action if name is in use to Keep existing object unchanged, see the image below:
HTH
Related
SQL Server 2012, 2014, 2016 transactional replication
Publication is created. (copy Foreign Keys is false, the default)
Subscription is created.
Snapshot and sync.
Turn off synchronization.
Upgrade the publication database.
Upgrade the subscriber database for tables affected by modified views.
Set the snapshot to only gather information for changes.
Restart sync.
There is now an error at the subscriber because the two new columns exist and the snapshot is trying to create them but with foreign keys.
Typically it hasn't cared but now it seems to because of the FK creation it wants to do. If I manually delete the two new columns the sync will now create them again but with FKs.
The same operation happens for other new fields but we've never run into this issue before.
Looking to understand why FKs are being sent and if there is a workaround or setting.
We have replication setup on two 2016 servers. Distribution and publisher are on the same instance. We have transactional replication running at this time with no issue. We are trying to add a new table to replication and these are the steps we followed:
Going to properties of the publisher. Articles. Checking off the new table to be added. Clicking ok, does not prompt to reinitialize (which is what we want).
Go to replication monitor, start the snapshot agent to take partial snapshot. In this scenario one article is generated (one table is chosen).
after this nothing happens. Table does not appear in subscriber database.
allow-anonymous is false and immediate-sync is false.
Am I missing a step or could it be a different issue?
Working on SQL server 2016 SP2-CU8 installed on both servers.
I suggest you check the following two options of the published article: Create Schemas at Subscriber and Action if Object is in use. The first one must be set to true and the second one you can set to Drop and Re-create if your application logic allows this. If you cannot allow to drop the destination table then at least the first option must be set to true for the replication agent to automatically create the destination table if it is missing. See the below image for the mentioned options:
HTH
I faced the same issue and fixed it by changing the allow_anonymous and immediate_sync properties back to TRUE and then turned back FALSE again.
That worked like a charm.
After adding table to replication it appears in sysmergearticles with status "6" and its not changing after sync, so replication always make drop/create table at subscriber. It started to appear suddenly and i have other tables that works good, but since several days i can't add table to publication without having this issue.
How do you preserve the File Group on the Subscriber of a Merge Replication Publication?
I created identical databases with 3 filegroups for various groups of tables, assigned to the appropriate filegroups when the tables were created.
The first time I created a publication (populated publishing database first, data went into correct filegroups) the tables on the subscriber were all dropped and recreated in the default filegroup of the subscriber.
OK, so I changed the "Action if name is in use" property to Truncate data in destination tables on initialization: snapshot ran fine, subscriber sync failed because it said it could not execute the script to add the rowguid column to the tables.
So what is the best way to keep the filegroups from changing? I want the data to go into the desired file groups when it is pushed by the publisher to the subscriber.
After yet more research, it turns out there is a flag in the the Article Properties called "Copy file group associations" which is set to FALSE by default.
It wouldn't let me just change it, had to rebuild the publication, but doing so and setting the FLAG to true recreated the tables with the desired Filegroups on the subscription databases and after snapshot creation, the subscriptions pushed and the data flowed into the correct filegroups. Sweet!
We have replication setup on a database and is working fine.
Now we want to update the database on publisher. So using installer we updated the database but we are getting errors like cannot update table as table is in use.
So how can we update the database which is part of replication?
DML changes (insert, update, delete) will work as expected and replicate to subscribers. By default schema changes (DDL) will be propagated to subscribers on synchronization, publication property #replicate_ddl must be set to true. There are some exceptions which can be found in Making Schema Changes on Publication Databases.