At 10:38 AM 01-08-02 +0200, you wrote:

>As far as I understand, shadow files must be local. I have to update the data
>on a second machine.

Shadowing can be done to a different machine - since its purpose is to
provide failover coverage for the physical failure of the server
machine. It is *not* replication, though. It doesn't provide failover
protection against a sick server which is writing corrupt data. The
shadowed data will be corrupt as well, then.

> > If shadowing can't provide the coverage you need then what you
> > are probably looking at is some kind of replication solution involving
> > triggers that fire when a DML operation occurs and use the event mechanism
> > to signal a server-based application to update tables on the "foreign"
> > server..
>
>Triggers/events are ok. But how can that server-based application know which
>update to send to the foreign server? Is there a way to let an external
>application know the SQL command used in an update?

Replication is a whole ball-game of its own. You can roll your own, or
purchase software for the purpose which is designed to be configured to
suit your requirements - see http://www.replication.co.za/

A middle way is to use the one-way replication components from IB Objects,
which provides the means to set up a replication service that runs
continuously in the background on a Windows server. See
http://www.ibobjects.com/iborpl.html

>Or could we somehow apply all updates of a transaction to a remote database?

That's what replication systems do, by one means or another.

heLen

All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org ·
http://users.tpg.com.au/helebor/
______________________________________________________________________