views:

40

answers:

2

I added a table tblJoinCustBlastList to a merge replicated database and now I'm getting this failure error during replication:

Error messages:

The schema script 'if object_id(N'[dbo].[tblJoinCustBlastlist]') is not null exec('ALTER TABLE [dbo].[tblJoinCustBlastlist] ADD CONSTRAINT PK_tblJoinCustBlastlist PRIMARY KEY CLUSTERED ( JoinID ) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

')' could not be propagated to the subscriber. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147201001) Get help: http://help/MSSQL_REPL-2147201001 Table 'tblJoinCustBlastlist' already has a primary key defined on it. (Source: MSSQLServer, Error number: 1779) Get help: http://help/1779 Could not create constraint. See previous errors. (Source: MSSQLServer, Error number: 1750) Get help: http://help/1750

All of the help links are dead. The table which caused the replication to fail (rblJoinCustBlastList) only has 3 fields:

JoinID -int- Primary Key - no nulls

fkCustID - int- no nulls

fkBlastListID - int- no nulls

and the system-created field Rowguid - uniqueidentifier

For my own troubleshooting, I removed this table from the articles to be replicated and then I even deleted the entire table from the database. When I tried to synch again to see if the error cleared out, I got the exact same message! Why is it giving me an error on a table that's not even supposed to be replicating, and is even deleted? And how do I fix this? Please help a newbie, none of my users can synch now...

A: 

This isn't the perfect answer to the question but easiest solution is likely to start with a new snapshot and push that out to the hosts.

When you have a lot of replication hosts I have found that Merge oftentimes does a Round Robin so changes adding / remove from servers would go round in a circle for weeks if you didn't start with a new snapshot when you made a schema change.

The errors are

MSSQL_REPL-2147201001 - Failure to create directories for temporary snapshot files 1779 - is the message when you try and add a primary key to a table that has one 1750 - is the message when you try and fail to create a constraint

u07ch
Thank you. By "new snapshot", do you mean I'd have to apply an as-is snapshot of the publisher to all the subscribers and have them lose all data since last synch, like a reinitialization? I'm hoping that's not it because there is a lot of data that would be lost. I did run the snapshot agent to the publisher after my schema changes, but that did not fix it.The error messages confuse me because I did not do anything to constraints and I did not try to add a primary key to a table that already had one. Even so, why would I be getting this message when the offending table is deleted?
dkimbrell
My experiences with Merge replication is that Schema changes have a nasty habit of rolling around the subscribers. It got so that we only do schema changes so long as we can republish the snapshot because we found tables appearing and dissapearing on subscribers systems. You should be able to address the directory / space issue easily enough. In terms of the table issues. You may be able to use http://msdn.microsoft.com/en-us/library/ms187946.aspx (sp_scriptpublicationcustomprocs) to get the scripts needed to fix the subscribers databases.
u07ch
Really, schema changes cause replication issues?! "Buggy" replication issues are the exact reason we left Access, I did not expect this from SQL server. Thanks for the warning.So there is no way I can fix this? I'll look at the Insert, Update and Delete scripts, but I'd like to use that as an absolute last resort.
dkimbrell
A: 

I fixed it by removing the table tbljoincustblastlist from the subscriber. I had removed this table from the publisher, but not from the subscriber and it was causing an error somehow, I presume it had something to do with a primary key constraint. whew!

dkimbrell