title: Avoid schema mismatch in System-Versioned tables
body: <p>Looking for a workaround for:</p>
  
  <pre><code>Error: SQL71609: System-versioned current and history tables do not have matching schemes. Mismatched column: 'XXXX'.
  </code></pre>
  
  <p>When trying to use SQL 2016 System-Versioned (Temporal) tables in SSDT for Visual Studio 2015.</p>
  
  <p>I've defined a basic table:</p>
  
  <pre><code>CREATE TABLE [dbo].[Example] (
      [ExampleId] INT NOT NULL IDENTITY(1,1) PRIMARY KEY,
      [ExampleColumn] VARCHAR(50) NOT NULL,
      [SysStartTime] datetime2 GENERATED ALWAYS AS ROW START HIDDEN NOT NULL,
      [SysEndTime] datetime2 GENERATED ALWAYS AS ROW END HIDDEN NOT NULL,
      PERIOD FOR SYSTEM_TIME (SysStartTime,SysEndTime)
  )
  WITH (SYSTEM_VERSIONING=ON(HISTORY_TABLE=[history].[Example]))
  GO
  </code></pre>
  
  <p>(Assuming the <code>[history]</code> schema is properly created in SSDT). This builds fine the first time.</p>
  
  <p>If I later make a change:</p>
  
  <pre><code>CREATE TABLE [dbo].[Example] (
      [ExampleId] INT NOT NULL IDENTITY(1,1) PRIMARY KEY,
      [ExampleColumn] CHAR(50) NOT NULL, -- NOTE: Changed datatype
      [SysStartTime] datetime2 GENERATED ALWAYS AS ROW START HIDDEN NOT NULL,
      [SysEndTime] datetime2 GENERATED ALWAYS AS ROW END HIDDEN NOT NULL,
      PERIOD FOR SYSTEM_TIME (SysStartTime,SysEndTime)
  )
  WITH (SYSTEM_VERSIONING=ON(HISTORY_TABLE=[history].[Example]))
  GO
  </code></pre>
  
  <p>Then the build fails with the error message above. Any change to the data type, length, precision, or scale will result in this error. (Including changing from <code>VARCHAR</code> to <code>CHAR</code> and <code>VARCHAR(50)</code> to <code>VARCHAR(51)</code>; changing <code>NOT NULL</code> to <code>NULL</code> does not produce the error.) Doing a <code>Clean</code> does not fix things.</p>
  
  <p>My current workaround is to make sure I have the latest version checked in to source control, then open the SQL Server Object Explorer, expand the <code>Projects - XXXX</code> folder and navigate to the affected table, then delete it. Then I have to restore the code (which SSDT deletes) from source control. This procedure is tedious, dangerous, and not what I want to be doing.</p>
  
  <p>Has anyone found a way to fix this? Is it a bug?</p>
  
  <p>I'm using Microsoft Visual Studio Professional 2015, Version 14.0.25431.01 Update 3 with SQL Server Data Tools 14.0.61021.0.</p>