Thanks Woody,

I find your idea quite interesting but I have a few questions:

I take it that when you say update, you are referring to a database
script.

If I understand you correctly, then you have a folder with all your
updates (scripts) in it. You have a program that looks at the scripts
and checks to see if they are in the update table in your database.
If it is found then it doesn't run it but if it is, then it runs the
script and then adds it to the update table. Correct?

The big question: Anytime I run scripts I use either Marathon, or
QuickDesk, or IB Console.

What program are you using to run the scripts? Is it something you
wrote? Is it part of your application or is it a stand-alone program?
If it is a stand-alone program .... is it for sale?

We have a DOS based application (that the Interbase Application is
replacing) where we currently have the EXE on the Internet where
clients can freely download and install on their own. The EXE handles
any database changes (DBFs).

Currently we have to dial into clients and install the new releases
manually but we would eventually like to get the Interbase Version
working the same way where clients could download a new EXE (and
database change scripts) and have it install the entire release.

Todd

--- In ib-support@y..., "Woody" <woody.tmw@i...> wrote:
> From: "Todd Brasseur" <todd.compass-cama@h...>
> 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