New upgrade step drop tables

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.

@René W 

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.