Comments
3 comments
-
Thanks for your post.
We've fixed this issue internally and do a full table rebuild instead (if the field modified is part of a primary key).
We're hoping to do a point release soon that includes this fix: no definite timescales yet I'm afraid, but I'll notify you with any developments in this area.
Alice.
Project Manager
SQL Tools -
alice.easey wrote:Thanks for your post.
We've fixed this issue internally and do a full table rebuild instead (if the field modified is part of a primary key).
We're hoping to do a point release soon that includes this fix: no definite timescales yet I'm afraid, but I'll notify you with any developments in this area.
Alice.
Project Manager
SQL Tools
Has this been released? -
I too would be interested to know if this has been released as I have this exact problem.
Add comment
Please sign in to leave a comment.
If the name of the primary key has been changed on the local database, then SQL Compare will issue a 'drop constraint' to recreate it using the new name, but that doesn't seem to be allowed in Azure:
As a minimum, you could include a warning in the warnings list, alternatively do a full table rebuild instead, as you do with major datatype changes (when you see that the target is Azure).
Another idea would be to include a sort of "Quick-options" for Azure targets, so that the user easily could set all the necessary Ignores to make it work.
Thanks for a wonderful product.