Nick Upson wrote:

> I've just found this quote "On the other hand, the source for simple
> data-based replication is included with the Firebird source. It's in C, uses
> the events API of Firebird, and is used by many open-source replicators."
>
> http://www.bsdforums.org/forums/archive/index.php/t-8162.html
>
> is this in the examples directory or somewhere in the code for firebird
> itself?

Building a one-way replicator is not very complex. You just add triggers
to tables that detect changes in fields (NOT DISTINCT in newer FB
versions makes code for such triggers much more readable) and when it
happens either:

a) store the change to some log table OR
b) have a flag field in the actual table to hold the 'change info'

There's a special application that monitors this and when change is
detected it:

a) reads the log forward from last known change and goes through all
changes - repeating them in the target database(s) OR
b) reads in the flags in actual table and makes sure that records goes
across

a) approach is much cleaner, esp. regarding deletes, but your log
table(s) should be able to cope with all data types that you wish
replicator to support

Of course, when you really start making something like this, you'll see
that there are small gotchas all around. Most of those do no exists with
one-way replication (to a database that nobody uses), but here are some
that do:

- make sure replication triggers fire AFTER and last (high POSITION)

- you need to update metadata to make sure both db's are in sync. Maybe
even disable replication while metadata is upgraded

- when you decide to bring the replicated copy alive there are some
operations that need to be done:

1. bring all triggers back online (it's easiest when triggers are
disabled during replication)

2. set correct values for all generators (they will surely go out of
sync with main database)

Well, this is just off the top of my head, but I'm sure you get the
general idea.


--
Milan Babuskov
http://www.flamerobin.org
http://www.guacosoft.com