Bug found in SQL Compare

• 
  Hi @JamesPhillips,
  
  Thanks for letting us know. One of my colleagues in the development team will get back to you shortly.
  
  Roseanna

  Roseanna February 25, 2019 16:41

  - 0 +
• 
  Hi James,
  
  We have logged this as case SC-10433 and will investigate for you. It may be worth trying a more recent release - 13.6.11 is available for download.
  
  Best wishes,
  Julia

  Julia.Hayward February 25, 2019 16:42

  - 0 +
• 
  I have updated to 13.6.11 and the behavior is different.   While it would complete without error it is also doing some unnecessary actions.  Below is the script behavior now.
  
  Drop clustered index
  ALTER the Column to NULL
  Create Clustered index
  Add default constraint
  Update column= DEFAULT
  ALTER column to NOT NULL
  
  The column was already NULL so the first three steps are just added I/O and time.
  
  
  

  JamesPhillips February 25, 2019 18:33

  - 0 +
• 
  I can't actually replicate this behaviour - can you provide some example scripts?
  
  When I attempt to deploy a nullability change with a default constraint and an index, it does the following:
  
  Drop index containing column to be changed
  Alter the column to NULL (which may be superfluous - this is where all other field changes would be applied if there were any, e.g. data type changes with implicit casts)
  Add default constraint
  Update column = DEFAULT
  Alter column to NOT NULL
  Re-create index containing column that was changed
  
  If we don't drop the indexes that interact with the default constraint, SQL Server won't let us alter it to NOT NULL, so we do have to drop the index and re-create it - but if you have a script in the order you've given, that's definitely wrong and something we should look into (and I'm surprised that it worked, unless the index here is unrelated to the nullable column?).

  Michelle T February 28, 2019 14:53

  - 0 +

Add comment

Please sign in to leave a comment.