Dalton,

That sounds very interesting but I know it would have to be done via
modifications to the server itself. I would prefer (for now) to find a
solution that will work with the existing versions of InterBase since it is
a requirement that I have to support them (where I work).

In short, there isn't enough functionality in InterBase to tap into a
journal of changes in committed order. Your steps are eventually going to be
trod but I think we can get there in other ways for simple replication
solutions.

One of the problems with replication is records are written out but
potentially become committed in a different order than they were modified.
This means that you cannot use any serialized ID to base the replication of
clients on. You would have to be able to have an OnCommitted trigger to go
around and serialize things with. Without this, the only way you could with
reliability insure all items were replicated to nondescript clients is to
use a strike-out list so that it knows when skipped parts need to be gone
back to. However, this would only work well if the series from the server
was unbroken, which with rollbacks we cannot assume. It's a quandary!

Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "Dalton Calford" <dcalford@...>
To: <IBObjects@yahoogroups.com>
Sent: Tuesday, April 10, 2001 5:49 AM
Subject: Re: AW: [IBO] Offtopic: Data replication.


> 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
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>