Sure. Let’s see if I can be coherent…
In 5.0, you could only compare in one direction. Since I usually had changes to make in both directions, this was bad. Really bad. I complained, and Quest listened. Kudo’s to Quest! A later patch mostly fixed this, by allowing for reversing the source and destination with the click of a button. So, that was good.
I am going to make a brief digression here to explain how we use schema compare, on the assumption that it will help you to better understand where I (really, we - all of us here at my company) am/are coming from.
We developers all have a copy of the DB on our laptops. We use Mercurial as our source control (it would be great it there was a way for TOAD to tie into that). As we work on a section of code, we sometimes have to modify the DB. We modify our local copy of the DB. Then, when we are ready to push our completed changes out, we will synch up our DB instance with the dev server’s. Since there are several of us working on the same Dev instance, there may be changes from another programmer already on the server. So, we do a compare, and pull in the table, view and stored procedure changes from Dev. Then we do another compare and push out our table, view and stored procedure changes to dev. Then we do a final compare, to ensure that all is well. So pull, then push, then check. (As a side note, the production server has centralized management and controls, but the dev server is more open, to allow for rapid development, prototyping and testing.)
End of digression…
In 4.6, there is an expandable tree view that is very easy to navigate. Since we all have separate instances of the DB, our permissions, roles and other privileges may vary slightly from machine to machine. I don’t care about those items at all. I don’t even want to see them. I just want to look at the tables, and see which ones need to be synch’ed up. And then I want to do the same thing for the views and the stored procedures. In 4.6 this is very easy to do - expand the tree view for those particular items, and only show items with differences. Then I know that I need to push those 3 tables, pull those 2 tables, and so on. It defaults to everything unchecked. I click on those few checkboxes I need, and off I go. It’s very easy. It’s very clear. It’s very understandable and intuitive. It’s also very easy to explain, train, and (for Quest) demo during a sales presentation.
So, finding the items I need to look at is very easy in 4.6. Then, if I am curious about an item (what changed in that particular table?), for instance, to see if maybe I and another developer both altered the same table, I can easily do so. It is easy and intuitive to drill down into an item. I click on the item, and then I can see that the columns and indexes have changed. I then drill down into the columns, and I can see that a column was added, or a column type was changed. I can see that an index or foreign key was added. It’s easy to see, and easy to understand. It also lists the code changes right there, in a side-by-side window. The highlighting of changes could be improved, but it’s still good, everything is right there, and I find it very easy to pick out the changes made.
In 5.5, you get these big area boxes (they used to be colored in 5.0). They list all sorts of different items. Roles. Permissions. Privileges. Statistics. Things I have somewhere between absolutely no and zero interest in. And they default to checked. I have to search through the list (at least in 5.5 it’s organized by type of object), uncheck those meaningless items, and then hope I didn’t miss anything. This thread came about, at least in part, because, you guessed it, one of us missed something. And something got pushed that shouldn’t have. The presentation of the information is far less intuitive, far less clear, and far less user-friendly. I can tell at a glance in 4.6 what is going on. In 5.x, I can’t. Because of this, I never really feel comfortable that I am doing only what I want to be doing, and no more.
Then there is trying to find out what changed. It’s not nearly as easy, obvious or intuitive in 5.x as in 4.6. But 5.5 is better than 5.0. I can check all and uncheck all, and it lists all selected objects. So, it’s definitely better, but it’s still not as as good as 4.6. Also, seeing the differences is less obvious than in 4.6. I have to flip back and forth between script and properties.
In addition to the usability, 5.x handles some things in an odd way. For instance, if you try to synch an encrypted table, it will list the table as being different, but won’t let you select it, and won’t explain why. 4.6 at least explains why.
The paradigm that I need, and that 4.6 has, is type of object first, location of change second (source, destination, both). The type of paradigm that 5.x seems to use is type of change first (source, destination, both) and then type of object. This paradigm is extraordinarily painful for me.
The 5.x paradigm also means that there are what feel like hacks to try to improve the usability. Like the “selected objects” pane. If you had a more usable paradigm, would you still need it? Or would it be as necessary? I really need a tree view showing me, by object type, what has been selected. I have some tables on my machine that I don’t want to push. It’s not easy to find those tables in the 5.x view. It’s very easy to find those tables in the 4.6 view.
4.6 works really well. It’s usable. It’s clear. It’s intuitive. It’s easy to use. What I can explain in one or two minutes in 4.6 will take much much longer in 5.5 (and even longer still in 5.0), and still not be as clear.
As a final note, I like TOAD. I am the reason we are using it at my company. I championed it and brought it in-house. And, I am a manager here, so I can better see what all of the different programmers are doing.
I know this is really long. I hope it gives you some of the information you need.
J Fischer