The above statements is something that most users do not realize when using pre-deployment scripts. Since the pre-deployment script is included in to the deployment script, it therefore by definition runs after the comparison the the source model with the target database (model), and therefore cannot change the behavior of the deployment.
If you know you have an orphaned object that is blocking a certain upgrade scenario, most users expect that when you would drop the offending object in a pre-deployment script, that this would take care of things. However the deployment engine has already performed the comparison between the source model and the target database (model) and generated the deployment script based on the results.
In order to gain a better understanding about what is going on, lets step through the flow of activities inside the deployment engine.
Now that we better understand the order in which operations take place, we can conclude that “pre-deployment scripts can never change the outcome of a deployment”, and that we really need a pre-pre-deployment script that runs before the model comparison is taking place in order to influence the outcome of the comparison and therefore the outcome of the deployment engine.
GertD @ www.DBProj.com (aetk39ypwb)