<?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/5543553#M45015</link>
    <description>&lt;P&gt;Nothing on the client side yet but from what happened last time once several of these were in the DB we saw the problem. Perhaps I misunderstood what the tech and developer were saying that they would 'handle' these conflicts via the hotfix.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;The official word from autodesk is that we will still see the null values (and conflicts) in SQL and they will not get cleared, but they won't affect SQL replication?? I sort of thought the hotfix was introducing a stored procedure to handle the conflict to ensure they don't dump the nulls in the database in the first place but like I said I could be wrong.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I opened a new case referencing this one to see if I can get official word, or maybe even have someone check our DB to ensure the new stored p is actually installed/applied&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Mon, 16 Mar 2015 21:46:47 GMT</pubDate>
    <dc:creator>Anonymous</dc:creator>
    <dc:date>2015-03-16T21:46:47Z</dc:date>
  </channel>
</rss>

