When you make alterations to the model, especially the data part that results in an upgrade script, there a plenty scenarios that break at actual upgrade. Especially for new users, because it's not always that obvious.
I would like to see the SF dealing with this scenario more elegant. And it should be not that hard to offer some kind of rollback. Because all the info is there to upgrade, so also all the info is there to return to start.
I am thinking about:
- Making especially the upgrade part interactive. Especially to have before the deletion of the temporary tables the choice to delete or rollback, in case of any error occurred.
- Or perhaps a separate task to reinstate the original tables, so you can fix whatever went wrong in the model and rerun the upgrade.
Now you have to 'hack' your way through it via SMSS or go for restoring a backup.
Which would also be a good and probably simple addition to the SF. Every upgrade should have the option to automatically create a backup before execution.
Yes! Yes! This!
I agree with Freddy here, I think it is trivial to reverse the backup based on the information that is available.
Steps could look something like this:
A rollback option in SF or even a fully featured undo mechanism would definitely great in the software factory.
What I’ve been doing these past few years is I’ve made backup and restore tasks in the developers menu of our end-product. What these tasks do is create a backup of the current database and rollback the last known backup file of the selected version. I quickly found myself going through the backup and restore options in SSMS all too often and then decided tasks would be much more useful.
Of course these tasks aren’t used in the actual end-product but they are in the dev versions of our end-product. Before every dev database upgrade I now only have to click the backup button to save the current state of the database. Then when I upgrade the dev database and something goes wrong all I have to do is click the restore button and wait a minute or 2 and I can start over.
Not yet, but considering the amount of votes we'll consider it for the 2023.2 release. We did make a start with preventing old tables to be dropped when the data migration failed for any reason. I do think the wishes here could be taken into consideration and that we could pick this up for the next release. If we do plan this idea, the status will of course reflect that.
Great, let me know if you need any input. Happy to help.
All the votes have been transferred into this idea.