From: "Todd Brasseur" <todd.compass-cama@...>
Sent: Monday, August 13, 2001 12:45 PM

> 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.
>

What I do is create an Updates table in the database. In the update file,
there is a unique update # for each update. This number is looked for in the
Updates table and if it's not found then it is allowed to run. This prevents
an update from running more than once and keeps me from having to compare
table structures. It makes it so easy that I can take the original version
of the database and run all updates at once. The updates run in a sequential
order because the later ones rely on the earlier ones being done. You would
have to work out what type of numbering scheme you want to use but it's
fairly simple to implement.

HTH
Woody