From: "Todd Brasseur" <todd.compass-cama@...>
Subject: [ib-support] Re: Syncronizing Databases

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

Yes, of a sort. It's my own make which is nothing but a text file. Looks
something like this:

[BEGIN UPDATE]
UpdateID=100.00C
UpdateName=Add New Fields
DatebaseName=TheDatabaseNameHere

[ADD FIELD]
TableName=SomeTableNameHere
FieldName=AddThisField
FieldType=7
FieldSize=0
FieldName=AddThisFieldToo
FieldType=4
FieldSize=0
FieldName=AndThisOne
FieldType=4
FieldSize=0
[END]

[DELETE FIELD]
TableName=SomeOtherTableNameHere
FieldName=RemoveThisField
[END]

[END UPDATE]


The field types here are for Access but can be changed to reflect IB fields
as well. It depends on which database I'm using. Non-text fields don't
require a length but it's easier to pass over them than to check if I need
it. (lazy, huh?) I keep one file with all updates in it and use that to
modify a database. With this structure, I can read the update and set up the
database connection. Then, perform each update action inside a loop until
the [END UPDATE] is reached.

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

I supply my clients with an Update program that is generic but specific to
the database type used. (i.e. Access, Interbase). I can email them the
script file and have them save it in the update program's directory and then
they can run the update. The program takes care of reading the update file
and performing any updates if needed. As each update is run, the table is
updated to reflect it.

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

The update program I have isn't for sale but I suppose with a little extra
effort, I can make it good enough for a free-ware solution. I am still
working on the Interbase version since I just switched over a couple of
months ago. There are some additional pieces of information for some field
types such as blobs, etc. that I am still programming into it. However,
since there are so many different styles of user access used (i.e. roles,
user log in, read/modify rights) it may be difficult to make something
generic enough to add tables AND grant rights to it. I am thinking more and
more that I need to just make this a component that you can wrap your own
special handlers around. It will probably be written using IBX, though, so
if you don't have it installed, it probably won't help you.

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

This would work great then as they could just download the update file. You
could build the update portion into your program or do what I do and provide
an administration program to run it.

Email me directly if you'd like to continue this discussion or go over more
specifics.

Woody
woody.tmw@...