Thank you for your comprehensive reply, Mr. Caine.

I will comment your evaluation below.

> > What I do im my consistancy check is rather simple.
> > The idea is this:
> >
> > Register your metadata through a stringlist (the way it displays

in

> > your IBConsole).
> > The DBMaster will parse through this SQL design script and

organise

> > the data.


> A lot of this is schemacache, isn't it?

Yes. DBMaster covers among else list of Table-, ExternalFunction- and
View-objects. A Table object covers field objects and so on.

Would actually be not too difficult to upload and merge databases
into one single design, but that's besides the point.

>
> > In case you need to take some precautions, you may register
> > the "Before" and "After" event routines on:
> >
> > TableCreate,TableDrop,TableAlter,FieldAdd,FieldDrop,TriggerCreate,
> > TriggerChange,ExternalFunctionDeclare,ExternalFunctionDrop,
> > IndexCreate,IndexDrop,ForeignKeyAdd,ForeignKeyDrop,ViewCreate and
> > ViewDrop.
> >
> > In many cases, this should mean you can start your utility, push
> > the "Update DB" and "Preview DB Document" button because the DB is
> > already designed in your app.source. And the update doesn't affect
> > more than what you specify. It should cover most but's and

maybe's.

> Not something I would ever put in client applications. I
> either give them a new database and a pump button, or I do
> it myself ( if they are paying for maintenance ! ).

In most cases I agree with you. That goes for my current projects
too. They will not be served to the menus of the project, the GDB's
will be disconnected, backuped, copied and tested. If everyting works
out fine, I just run it all over again on basic DB and reconnect. I
have not yet needed to use backup for user data for my project. So
far, everything has been a few tables added/dropped, single fields
added/dropped, indexes created and really simple stuff actually.

The way I presented this is of course just the basic idea. Also, this
component would probably be useful only to customer specific
projects.

> > I am alone though. If I do this whole thing all by myself, I will
> > have to claim bankruptcy very shortly. That means all I can do is

to

> > approximate this to what I need for my current projects, and that

is

> > not good enough for IBO.


> I does sound something of a half way house. I have to manage
> which versions of library are needed on a particular site,
> what modifications to the database are needed, and their
> current bug list. An automatic update old database to new
> database sounds too dangerous to me. I need the backup and
> restore, and the existing pump so I see no advantage in
> modifing the existing database. If there is a major 'cockup'
> then I like to be able to go back to the stable state and
> start again. Yes I know you just restore the backup, but
> that does not help isolate the problem.

Oh yes, half way house it is and will probably always be. This method
of maintenance has a limited usage. Like any other component, you
don't use it if it doesn't cover your needs. In order for this
component to cover all instances, it will probably have such a
developer interface that any other alternative would be easier.

I have about 50 tables in one of the DB's here. The update statements
I end up with, can fully be covered by the way I design this. With
only a few precautions, like when I add a field and it needs to be
filled with values. Just an example of what can be covered by an
AfterFieldAdd or AfterTableAlter event.

> I keep saying it - how do you handle the problems due to
> data errors that you have not seen in the test database -
> there always seem to be the odd record that causes a
> problem, and its how you recover from that that I see as the
> problem. At least with the pump you can isolate a problem
> and deal with it. With changes to the metadata, the
> underlying data can become unaccessable and then you have
> the problem that I am trying to avoid.

This is not meant to replace any of the IBO's very impressing
components or error detecting tools. It is only meant as an easy-to-
use tool to update the structure itself, to allow or not allow a
specific update and to give options for additional positioned and
conditional queries to the process. It can cover the whole DB or just
parts of it. And of course, whenever this component no longer can
cover the developers needs, he/she can simply take it out and
continue on the basic it created.

> Any tool like this is a development tool not a client
> application and therefore if limited interest when there a a
> number of ways of handling it.
> Geoff tool may also have the same limited appeal, BUT backup
> and restore safely accessable is the one thing that is
> missing at present.

That is a very honest and therefore appreciable statement. I will
limit this component and development of it due to my own needs. My
needs doesn't always reflect other peoples needs, so I really
appreciate that you took the time to assess this.

Best regards,
pfewww