Subject | Re: [firebird-support] Replication |
---|---|
Author | Dimitry Sibiryakov |
Post date | 2004-01-27T07:40:23Z |
On 26 Jan 2004 at 17:03, frische_brise2003 wrote:
IBPhoenix. They came from the same source, but go apart. If you plan
to use the latter, I'd suggest you to subscribe to ibp_replicator
mail list on lists.ibphoenix.com and ask your questions there.
IBPReplicator, IBPhoenix most likely will fix it. Can't say the same
about Borland.
Primary keys of replicated tables must be unique not only on
database level, but in all involved databases.
They must be constant (Updating PK value will confuse current
version of replicator).
Cascade delete will cause a lot of warnings on replication.
Altering replication tables on-the-fly most likely crash
replicator.
SY, Dimitry Sibiryakov.
>Now, I'm planning to use IBReplicator to keep the databasesPlease, distinct IBReplicator from Borland and IBPReplicator from
>in sync.
IBPhoenix. They came from the same source, but go apart. If you plan
to use the latter, I'd suggest you to subscribe to ibp_replicator
mail list on lists.ibphoenix.com and ask your questions there.
>My questions:Can't say much good, but it works. If you find a bug in
>- has anybody already used IBReplicator and can tell me his
> experience?
IBPReplicator, IBPhoenix most likely will fix it. Can't say the same
about Borland.
>- on which topics do I have to keep keep an eye on when IFrom the top of my head:
> design my database (e.g. primary keys, generators....)?
Primary keys of replicated tables must be unique not only on
database level, but in all involved databases.
They must be constant (Updating PK value will confuse current
version of replicator).
Cascade delete will cause a lot of warnings on replication.
Altering replication tables on-the-fly most likely crash
replicator.
SY, Dimitry Sibiryakov.