Embarcadero Change Manager
Another primary function of CM/Schema is the comparison of databases and/or archives. This task is also completely wizard-driven.
As I have mentioned some lines above you can use CM/Schema to compare live databases and archives in all possible combinations. For the purpose of my discussion here I will compare the archive I just have created with a live database.
Here the next step is to select the archive you wish to use in the comparison process. As you can see from the screenshot above, you can use any archive on any registered datasource for the comparison. Worth mentioning here is the fact that you can also use archives created with a previous version of CM/Schema.
This image illustrates the various options you can activate or deactivate for the comparison. There are several options which are activated by default, while others need to be manually activated. The above screenshot shows the default setting.
For databases with multiple users/schemas you can specify the scope of the comparison. The most comprehensive option is to compare all objects, irrespective of the owner. This is the default option. However, it is also the option that requires the most server resources and takes the most time. This can have a considerable effect on the runtime of the comparison process, especially on larger databases with many objects belonging to different users/schemas. For these cases, CM/Schema offers a feature to limit the scope of the comparison to either a specific user/schema, or to manually select a particular set of objects to include in the comparison.
The next step is to specify the objects being compared. From the above screenshot you might realize that certain object types specific to SQL Server 2005 are missing. For a pure SQL Server shop this might represent a drawback, but I’m tempted to say that most customers of CM/Schema run a heterogeneous database environment so that this drawback doesn’t weigh in too much.
A quite remarkable feature I would like to point out is the option of being notified only if differences are detected. So, everything is just working fine until you get a notification in your inbox.
After the comparison job is executed, you can examine the results in the main grid. In my example there is only one difference detected: tempdb.
A double-click on a list entry opens a new tab in which the particular comparison results are shown in detail. In the left pane you can see the code for the particular object in the comparison source, the right pane shows the corresponding code in the comparison target and the bottom pane shows the synchronization script.
At this point you have the choice to execute the synchronization script directly or schedule it for off-peak execution. From the screenshot above you see that you can execute the synchronization script for each detected difference independently from each other.