Comments
8 comments
-
@duncanbatchelor
I may have missed some detail but I think you could have kept the data in the table if you had written written your script to first add the new columns, after that put the data in those new columns and only as a third step you would alter the table to add the default constraint.
Then you could remove the old columns from both the table and the view and make the view use the new columns. -
Diogo, I appreciate your response. The issue is that there should be a mapping facility during the migration process, rather than having to jump through hoops. We achieved the result, but the question was posted here to see if there is a SIMPLE way to make the required change as there is in the VS Studio database projects. Thank you for your time and consideration in posting though.
-
In your Compare project, you can set up a table mapping, and inside that map the source and target columns. Compare will then understand that the correct scripting behaviour is to rename the column and then change the column type (rather than doing a drop and recreate, with resulting data loss)
-
Thanks you Julia, but this is in Source Control rather than a Schema or Data Compare, so wanted to find an answer for Source Control changes like this. But thank you.
-
Hi @duncanbatchelor!
I realize this would also be a workaround rather than a built-in SQL Source Control option, but I think adding a default constraint could also help. -
Hi Jessica
Thank you, and as a workaround this may work. The point is a bit moot now as we have resolved this manually. It would be appropriate to have this sort of feature built in for future users though.
Kind regards
Duncan -
Hi @duncanbatchelor,
We have a feature request for allowing users to define a default value when attemping to add a NOT NULL column to a table, logged with reference SC-1428. There's no ETA for this as of yet, but I've +1'd it with your details.
Thanks for your feedback!
-
Add comment
Please sign in to leave a comment.
The only way we could get around it was to run the TRUNCATE of the table, and DROP VIEW before, manually, and then run the deployment. It shouldn't be this difficult though should it?
Excerpt of the log, slightly redacted, below: