title: unexpected differences from Schema Compare in Visual Studio 2017
body: <p>I have this weird behavior of <code>Schema Compare</code> in <code>Visual Studio 2017</code>. </p>
  
  <ol>
  <li><p>When comparing 2 databases, two identical tables I get difference that one of those has no <code>PK</code> name. If I would script out tables using <code>SSMS</code> I would see that indeed on one of the servers table script seems not to have <code>PK</code> name, but if I would query <code>sys.indexes</code> table I can find that this index has a same name on both of the servers.</p>
  
  <p>One possible solution I found is to update the table, let's say add some random index and remove it, so I am guessing that it has something to do with how SQL Server stores the objects definition. But it would be nice to know what is causing this and how to solve it in the right way and not with some kind of workarounds.</p>
  
  <p><a href="https://i.stack.imgur.com/R7h9B.jpg" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/R7h9B.jpg" alt="PK_Diff"></a></p>
  
  <p>p.s. I know that the <code>PK</code> name is not "correct".</p></li>
  <li><p>Similar situation when comparing two identical <code>SPs</code>. I tried to run <code>sp_refreshsqlmodule</code> and <code>sp_recompile</code> but it didn't help. Updating <code>SP</code> helps, but again this is not very nice workaround.</p>
  
  <p><a href="https://i.stack.imgur.com/dYkNt.jpg" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/dYkNt.jpg" alt="SP_diff"></a></p></li>
  </ol>
  
  <p>EDIT 1: In the first example PK with the same name exists on both databases (even though the name is not following standards). The following query ran on both databases returns identical result:</p>
  
  <pre><code>SELECT I.name 
  FROM sys.indexes AS I
  INNER JOIN sys.objects AS O
      ON O.object_id = I.object_id
  INNER JOIN sys.schemas AS S
      ON S.schema_id = O.schema_id
  WHERE S.name = 'MySchema'
  AND O.name = 'MyName'
  </code></pre>
  
  <p>Result: <code>PK__TraceDat__AAAC09D801ED28A5</code></p>