Hi Jason,

Jason Wharton wrote:

> Here's the parts we need to figure out.
>
> Our own system metadata definitions. We will have tables that store how
> everything is configured. Changes to those table will trigger the governor
> service to implement those changes in the database. If successful the
> metadata will reflect the status, if not error entries will be given. This
> will make it really easy to setup remote administration of governor services
> do all the actual work.
>

I think I can be of some help there, having done the same with our own
stuff.
Biggest problem I have had is trying to avoid UDF's. Not being able to
pass certain data types around and not being able to get the current
table name or trigger name causes alot of duplicated code. It would be
much simpler if the engines logging ability was re-enabled. We could
create a program that would read the logs and apply it as needed,
without the need to have our own system tables. That would cover all of
our requirements because it would allow us to log every change
automatically(this is how oracle does it).

Since we would be able to write our own client that would apply the log,
we can implement any form of reconsiliation procedure we wish.

What I would love to see in IBObjects, is the ability to turn on a
session log, and to define multiple target Databases. If the connection
is lost to the current database, IBO would connect to the next in the
list and check to see the session status (how much got replicated over
to the secondary database) and apply any changes that have not made it,
including changes from the clients current transaction. In this way,
the end user would never lose work, and, if done as a background thread,
could continue working while the system updates itself.

Just some wishful thinking

best regards

Dalton