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.
Erwin,
In general the upgrade should be successful when all the validations regarding the upgrade process have been properly solved.
Users with allot of experience could also manually execute the upgrade step using the management studio. The upgrade script has been supplied with a header, that marks the section which drops the (old) tables.
You could firstly execute the section above this header and later on choose to execute the section below the header.
Unfortunately, this idea has not received enough votes. Because we want to keep the focus on ideas that are in high demand in our Community, we are closing this idea.
Find this important, so created a new idea to get this going again. So put your votes up, so that it will be implemented this time.