Comments
Sort by recent activity
EDIT: I'm sorry, after rereading your question, I now realize you wanted to be able to reverse a migration script. Sorry I missed that detail initially. I'll leave my somewhat out of context answer in the hopes that it may prove useful to someone!
As you noted, this isn't possible for all types of changes, but I've taken to using this technique with good success:
1) Run your compare, select your objects and create your deployment script through the deployment wizard. I like to save it under a name similar to:your_deploy_name.date.deploy.sql
2) After the wizard completes, you are dropped back in the compare screen. Do not change any selections!
3) Near the top of the compare screen, right-click the blue arrow between the two databases under compare and select 'Switch deployment direction.' The arrow changes to green and now points to the left. (Ctrl-D is a shortcut for this)
4) Rerun the compare wizard only this time name you file something simtlar to: your_deploy_name.date.rollback.sql
You now have two script files, one to deploy and one to backout.
As an extra verification step, I have TeamCity running locally and use it and various RedGate tools to:
1) Build a brand new image of our production database on our development server.
2) Run a compare to insure the two are identical
3) Apply the deployment script
4) Run a compare against source control. Either insure they're identcal or account for any differences.
5) Apply the rollback script.
6) Run another compare to insure we're again identical to production / comments
EDIT: I'm sorry, after rereading your question, I now realize you wanted to be able to reverse a migration script. Sorry I missed that detail initially. I'll leave my somewhat out of context an...
Yes, I can't say exactly which upgrade broke this, but it's not working for me either in ver 5.3.6.28 and I'm fairly certain for at least version prior to this. / comments
Yes, I can't say exactly which upgrade broke this, but it's not working for me either in ver 5.3.6.28 and I'm fairly certain for at least version prior to this.
Thanks for the reply, Chris...
After playing with this for a while, I suspect it has to do with default and check constraints, however I find it curious that the compare doesn't find (or at least display) any differences.
This is how the table type scripts out as a CREATE: USE [dev_cisitem]
GO
CREATE TYPE [stage1].[common_message_list] AS TABLE(
[common_message_id] [int] IDENTITY(1,1) NOT NULL,
[obj_id] [varchar](32) NULL,
[obj_type] [varchar](32) NULL,
[status_code] [char](1) NOT NULL DEFAULT ('S'),
[msg_source] [varchar](32) NULL,
[msg_level] [varchar](16) NOT NULL DEFAULT ('Informational'),
[msg_text] [varchar](128) NOT NULL,
[msg_parm] [varchar](128) NULL,
CHECK (([msg_level]='Abort' OR [msg_level]='Error' OR [msg_level]='Warning' OR [msg_level]='Validation' OR [msg_level]='Informational')),
CHECK (([status_code]='S' OR [status_code]='F'))
)
GO
/ comments
Thanks for the reply, Chris...
After playing with this for a while, I suspect it has to do with default and check constraints, however I find it curious that the compare doesn't find (or at least d...
Thanks for the update Chris...
I'll watch for your resolution.
-John / comments
Thanks for the update Chris...
I'll watch for your resolution.
-John
I believe this relates to bug SOC-4068
Details in msg 15456: http://www.red-gate.com/MessageBoard/viewtopic.php?t=15456 / comments
I believe this relates to bug SOC-4068
Details in msg 15456:http://www.red-gate.com/MessageBoard/viewtopic.php?t=15456