Schema Compare in 4.6, 5.0 and 5.5

I have mentioned this before (to product support), and some small changes have, happily, been made. However, I recently went into schema compare in TOAD 5.5 (accidentally), and had a severe allergic reaction. Why oh why did schema compare get so totally horked over in v5? If v5.0’s schema compare was a totally and completely unusable Mt. Everest sized pile of horse manure (and it was), then v5.5 is a kinda, sorta, maybe, moving in the right direction, almost usable Smoky Mountains sized pile of horse dung.

In the meantime, v4.6 is the highly usable and user friendly alabaster city on the hill.

The problem is, we have new programmers coming on board, and v5.5 so badly sucks in the schema compare dept that I am thinking I need to install v4.6 on their machines - just so they can do schema compares. I use v5.5 for everything except schema compares (and alter tables, because v5.5 consistently fails on certain alter table statements. I suppose I should submit this as a trouble ticket, huh? :-)).

v5 schema compares are, to put it bluntly, unusable. Please bring back v4.6’s method of schema compares!

Oh, I should mention: all of the other programmers here feel the same way I do. But I have the Quest account, so I get to complain… :slight_smile:

J Fischer

Hi Jonathan,

Thanks for starting this thread!

Can you please share with us more details on unusable schema compare?
What is your main pain in 5.5?
Is it usability issue or maybe script generation engine generates bad scripts?
What was the great in 4.6?

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

Thank you.

This is very solid post with good definition of your case and the problems you have experienced - I’m going to create a few precised requests for changes you are asking for.
May I contact you in a week or so to evaluate latest beta with some of the changes?

Valentine,
That is fine.

I was thinking to share with you guys new schema compare look and feel.
it is basicly very similar to 4.6 with an exception: the windows are dockable so you can re-arrange them in the order you like. For instance, treelist can display results as per change status or as per object types. Also you may see scripts & properties at the same screen - no need to switch. Don't blow up your imagination - see attachment.

What do you think?

Valentine,
That looks pretty good! It would allow me to filter to only those items I need to see. Is the object tree view collapsible? Like in 4.6? Or do you always see all objects?

Object tree view is collapsible like in 4.6. So you can focus on most interested changes. Here is another shot of the object tree view.
toad_schema_compare_lookandfeel02.png

Valentine,
This look good! I think I might be able to get my users off of 4.6 (and not have to do a dual install) with this approach. Of course, I will have to test it first, but it looks promising.

Valentine, Is this new schema compare going to be in version 5.6? I don’t see it in the beta.

Schema Compare will be available in next beta drop and will be in 5.6 for sure.
Current beta doesn’t include the changes we discussed. Sorry for inconvenience.

Thanks for the information! I will look for it in the next beta drop.