That's good overview of the schema compare facilities of DBPro but the example process you have chosen is fundamentally flawed as database changes should NEVER be reviewed at deployment time.  The time for deciding whether a change needs to be part of a build and deployment is when the change is checked in to the main codeline in a source control system, nowhere else.

Why?

Because that's the way that we manage all other code assets.

For example, if three C# class files have changed you would review any changes made (if that quality check, normally a peer review, is in your process) by using the source control system's history and diff functionality.  You wouldn't compare the current source files with the previous source files and pick and choose which changes are going to be deployed would you? No, you simply build and deploy what is checked in to the main codelines in source control and then test, test, test.  If the review picked up any less than desirable changes then they should be rolled back or a new version checked in to the source control system.

This pick-and-choose method of deployment is manual and error prone and means that you do not have a solid audit trail of what was in the release and, crucially, why.  The best you can do is look through the delta/upgrade script that was produced and attempt to infer what was, and wasn't, deployed.

I think we are so used to the old "write-an-alter-script-and-get-the-DBA-to-check-it" approach that we still use the same mentality when we start to use tools to help with changes.  We need to think differently - use source control for database changes and use the tools properly to manage those changes.

I think the first article in your series should have been about the database import and build functionality of DBPro...