--- In Firebird-Architect@yahoogroups.com, Jim Starkey <jas@n...>
wrote:

> Without evidence, I can't understand how you made that judgement.
> The work required is the same whether it is hardcoded inside the
> engine or executed inside a trigger. I don't think there is any
> doubt that trigger based replication is more flexible.
>
> As for administration, I will consider that the existing trigger
> language is less than optimal, but Java based, multi-table triggers
> with fast metadata access eliminate almost all of the problems.

Have to agree that trigger based replication is a lot more flexible -
but it's arguable that this very flexibility allows far more scope
for error.

Setting up a shadow is really easy and it should be relatively simple
to allow it to shadow to an adjacent computer over a dedicated
gigabit network cable without trashing the shadow if the other
machine is unavailable for a few seconds or minutes.

The nearest I have to a performance comparison is between shadow
mechanism and stnadards triggers. Daabase write time to a single
table rose ~30% with a shadow, and over 100% using a trigger to copy
changed records. It seems to stand to reason that the raw disk block
level version should be faster, but I haven't tried your idea of
taking the processing to an external process, so I'll have a look.

I can understand the desire to go with the more general solution as
it has to satisfy more people's requirements. It's just that
shadowing as it stands is rather pointless (given RAID), while a
network version would be a really useful and simple data security
mechanism.

Still - guess I have to live with what's there!

Thanks,

Tim