We have exactly the same situation.

There are tools out there that can determine the metadata difference and
generate a script to bring the target DB in line with the source DB. But
these tools are far from perfect. They dont look at dependencies and just
generate a script. You have to put the parts in the correct order yourself.
E.g. if a SP has changed by adding or removing a parameter, you have to
disable the calls to this sp in all dependent sps before you add the param
otherwise you break the db. Only then you re-enable the calls to the
changed sp. This example is a 3-step process that none of the tools provide
for. This becomes cumbersome for a DB with a lot of metadata.

We are in the process of building a tool that will do this, but it is quite
complex as you can quite imagine.

At the moment we keep close track of what we change and generate scripts
for each part.

At 17:45 2001-08-13 +0000, you wrote:

>We are trying to decide how to handle keeping our clients databases
>metadata the same as ours.
>
>We have a production database in our office which we are continually
>changing as our product evolves. Our clients have their own copies of
>the database with their data.
>
>Every once in a while, we give them a new 'release of the software'
>which includes the new program along with updates to the database. We
>are finding it quite alot of work to maintain 'change scripts' to run
>against our clients databases. The most work is in keeping track of
>which scripts have been run against which clients databases.
>
>Does anyone have a similiar situation? Any ideas regarding how to
>manage the database changes would be greatly appreciated.