I've seen a tool called SQL Integrator which does not only find
differences but also prepares upgrade scripts. It is from Transfer
Solutions but there is not much information on the web. I have the
e-mail address from the person who gave the demo:
pvaalATtransfer-solutionsDOTcom and assume your are welcome to ask him
for more information.
enzoweb_at_hotmail.com (Andy) wrote in message news:<8d4033cd.0205061731.2e270c25_at_posting.google.com>...
> I have used Quest Schema Manager in the past, but that is also very
> slooooooow. I've also used something called DB Tools from SoftTree
> Technologies, but guess what - it was slow.
>
> I haven't seen anything that works quickly, expecially when you
> consider what it has to do. OK, it can compare table names. And view,
> trigger, procedure names etc. Then it can compare the indexes on those
> tables. It'll then compare the columns on those tables, and the
> indexed columns. Then it'll look at the columns on the views. And
> that's the easy stuff. When it starts to get down to the level of
> comparing the code in Procedures, packages, triggers etc it's just got
> so much work to do.
>
> If you find anything, let me know, I have the same problem.
>
> .
>
> cestamper_at_yahoo.com (Chris Stamper) wrote in message news:<34d76e21.0205061458.58d6868_at_posting.google.com>...
> > I work at a development site where, probably like most, we have many
> > schemas floating around in different states. I need a tool that can
> > take a baseline from one schema and generate the sql needed to bring
> > other schemas into line--object structure-wise, not data.
> >
> > I have tried OEM's Change Manager. It has the right idea, but it is
> > so dang darn diddly arn slow, and it keeps pooping out after a few
> > hours. The benchmark schema has about 2600 objects, 360-some are
> > tables, lots of indexes, and about a zillion triggers, constraints,
> > sequences and little stuff. We have our own home-grown scripts that
> > can syncronize two schemas in about 4 hours. I was hoping the world
> > of tool development could have done better.
> >
> > Any suggestions or recommendations would be appreciated.
Received on Tue May 07 2002 - 10:39:14 CDT
