There are 3rd party tools that can handle DDL comparisons - BMC and
Quest Software both provide this functionality.

Comparing data in 2 tables is challenging;  had to do this for a
migration once.  It can be done with SQL, see the INTERSECT and EXCEPT
keywords.  :-)

Hello Serge,

Thank you very much for your reply.

Here is a typical scenario for DDL change: the developers may add
(quite often) or drop (not often) columns into/from tables during
development of an application, according to the data they see that are
needed for the application and was not considered in the previous
database design. Then when the next release comes up, they will
implement an upgrade script to include all the changes that have been
done to the application and the related software (which includes the
modification to the database DDL), in order to upgrade all the other
machines that run this application. If we can see what has been changed
to tables and columns, then we can write a SQL script to update all of
them at one go for each machine.

And here is a typical scenario for data modification: let's say an
application drives a real-time system (hardware), meaning the
modification to the data in the database can change the behavior of the
system. The developers/testers would change some parameters (which are
saved into and retrieved from the database by the app) to fine tune how
the system moves, how much the system moves, etc. At the end of the day
or at certain point when they are satisfied with the system, they would
like to see which parameters have been modified, do some analysis, and
eventually establish a set of parameters as template for the other
systems.

I guess the simplest will be a tool similar to the "diff" on Linux (I
assume a tool with a GUI will take much longer to develop), where it
flags all the tables that have been modified, all the columns that have
been added or removed or modified (such as column size), and if
possible, all the constraints, sequence numbers, & triggers that have
been added or removed. Difference on whitespaces and new lines can be
omitted. Actually for now just the changes to a table (adding,
removing, and modification of columns) should be enough.

Thanks.

The problem I've found with db2look is that it outputs the DDL in strict
"last created / altered" order.   The reason why is obvious : it makes it
easy to produce a DDL script which can run without any problems of "object
creation order" if you create it in an order which has run successfully
before.

However this format is virtually useless for doing a diff against.  

Another problem is that of differences of white space, indentation and the
like.

What I wrote is a little utility which strips out the white space and sorts
the statements from db2look in alphabetic order.   Not much use for
running, but the first step in identifying which objects have changed.

If anyone is interested I can make this script available.

Phil