<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Vault 2014 Professional SQL Data Conflicts in Replicated Environment in Vault Forum</title>
    <link>https://forums.autodesk.com/t5/vault-forum/vault-2014-professional-sql-data-conflicts-in-replicated/m-p/5476967#M45008</link>
    <description>&lt;P&gt;Hi Travis&lt;/P&gt;&lt;P&gt;after analyzing the dependencies to and from the MasterChanges table I found out that is has just 1 dependency to the Master table.&amp;nbsp;&lt;/P&gt;&lt;P&gt;I saw that NONE of the failing MasterChanges entries has a correspondig entry in the Master table. So this row does not make sense in the vault database - you can´t find out what this "thing" is (a folder, file,...) - it is just a useless entry.&amp;nbsp;&lt;/P&gt;&lt;P&gt;Additionally as you also found out this is true for all the subscribers.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;So I made a backup of my publisher database, stopped the database replication and deleted all those entries per sql delete script from the MasterChanges table in the database. Then I removed all the conflicts with the conflict viewer from SQL studio and activated the replication again.&lt;/P&gt;&lt;P&gt;All conflicts are gone since then and did not come back.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;No problems so far.&lt;/P&gt;&lt;P&gt;Unfortunately there is no official statement from Autodesk until now if this can lead to problems...but as replication was extremly slow this was the only solution to get everything up and running again...&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;klaus&lt;/P&gt;</description>
    <pubDate>Wed, 21 Jan 2015 13:18:55 GMT</pubDate>
    <dc:creator>Anonymous</dc:creator>
    <dc:date>2015-01-21T13:18:55Z</dc:date>
  </channel>
</rss>

