We had merge replication in SQL Server 2005 set up that was working fine, except when trying to view conflicts, the Conflict Viewer would give this error: “RowGUID is neither a DataColumn nor a DataRelation for table summary. (System.Data)”.
The source of this it turns out was actually a period in the Publication name, as we had a “6.1” as part of the name. Other special characters would probably also cause trouble.
The only way to fix this was to drop the replication, resolve known conflicts manually with a data compare, recreate the replication, and reinitialize. After that, we could use the Conflict Viewer to resolve conflicts successfully.
This was a frustrating issue since the replication was allowed to be created with the period and worked completely fine, only the Conflict Viewer experienced trouble and it gave an error that did not accurately describe the issue.
The moral of the story is: don’t create a publication with a period in the name.
Jeff,
I can confirm the same problem still exists in SQL Server 2008 SP1 and I have found NO other documentation regarding this issue.
IMHO it is a bug not a limitation. If periods are not allowed then validate the name of the publication before allowing it to be saved! It won’t allow merge publications if there is anything (ANYTHING) else wrong with your database but will allow the publication name to be saved to prevent resolving conflicts. Just ridiculous and has caused many hours of frustration!
I had exactly the same error and caused by that blasted dot. In my case I found out about it at the end of a republisher pushing out filtered subscriptions and had to roll all the way back to the central publisher and start all over again, again…
Another “dot-related” issue to be aware of for merge replication…
For example, I have schema [A] and schema [B] both have tables called [Info].
I have filtered replication going on A.Info and wanted to use joins to enforce integrity on other filtered articles.
So the example WHERE clause would be “WHERE A.Info.ID = B.Info.ID”
Joins in filtered replications ONLY support 2 part naming conventions!
This means the valid caluse has to be “WHERE Info.ID = Info.ID”
The builder is automated so you can’t alias anything and are stuck with it.
My work around was to create a seperate filter for each table rather than using the Joins.
Despite the setup issues with merge replication, once it is up and running it is great stuff.
I still recommend creating back up jobs on all subscribers (ours are SQL Express 2008) and purchasing RedGate’s SQL Toolbelt so data compares can be done in the case of failures or data loss.