This is an attempt to revitalize an old idea of
“If something goes wrong during the upgrade part of the execute source code most times you have to restore a DB to start over. This is very time consuming and not necessary. If the drop table part from the upgrade step is moved to a new step drop tables, which would be placed at the end of the execute source code. This would mean that if something goes wrong during the upgrade step you could still check the data to see what went wrong. After solving the problem you could then just run the script again, since the backup tables still exist.
The only reason I can think of why the drop table is currently in this step is the removal of domains. This could easily be solved by using global temp tables.”
As the old (renamed) tables are currently immediately dropped, you have no option but to restore a database. In the hope that the backup went well and you have enough rights to restore it.
When having this in another step, you always have the opportunity to improve the script, as generating it isn't always flawless.
Hi,
I'm just curious, what exactly is causing failing upgrades? How can that be prevented? Can for example some (custom) validations help?
Most failures here occur as far I know is by applying new constraints or new (mandatory) fields. People are not always aware that certain data model changes can affect existing (uncontrolled) data.
I'm also looking to some kind of validation that helps preventing the examples above. Some data changes need some review I guess.
Br, René
I agree with this idea, especially in the early stages of development or on development environments in general. What I usually end up doing is opening the upgrade script, hit ctrl-f to search for ‘drop table’ and cut everything after that into a new window/file. Then I execute the upgrade minus the drops and if (if, mostly it is fine) something goes wrong, I can still resolve the issue without resorting to a database restore.
This is especially useful when an external DBA needs to do the actual restore of the database rather than you being able to do it yourself.
Problems that most often occur, have to do with mandatory fields that get a (unique) default value, that is dependent on a new function that still isn't available op the database. Most often this occur when deploying to (a copy of) the customer database when multiple projects are combined into one deployment package.
All the votes from this idea have been transferred.