At 12:43 AM 28/07/2004 +0000, you wrote:

> > That's because there is a separate help file for the IBO Replication
> > components.
>I didn't find any link to this help file.

If you don't want to pay for the replication components, you can study an
html version of the helpfile by clicking on the link that's on the
Replication module's "Module" page on the main website
(http://www.ibobjects.com/iborpl.html). Also, the IB_RPL.dpr project in
your IBO root directory is a demo setup.

> > There is also a fairly substantial difference in complexity between
> > one-way replication and two-way.
>My replication system is many to many and uses application logic: the
>decision how to replicate things depends on application logic/data.
>The replication system was designed as part of the whole application
>solution and not as a stand alone replication tool.
>
>Anyhow the question was: "What is the best strategy with IBObject?"
>So maybe somebody with ibo replication experience can give a proper
>answer to this, since I don't have any experience with ibo
>replication.

Really, the answer should be "defining replication as part of an
application has recognised limitations." Simply put, the integrity of both
sides of the replication relation is totally dependent on one
application. It's really only "safe" where the application vendor has
tight control over what users do with the database; and it is between
"hard" and "impossible" to protect it from communication problems.

So--the "best strategy with IBObjects" would be to set up an
application-independent replication service using the IBO simple
replication components.

Note "simple". The IBO replication components can't be used to set up a
synchronous two-way replication system. You can achieve limited two-way
asynchronous replication with the IBO components by setting up TWO services
and relying on humans or OS scheduling to ensure that they a) operate in
the correct sequence and b) wait for one service to finish before starting
the other. It's safer than application-dependent replication but it's still
at the low-calorie end of replication requirements.

By contrast, a user-application-independent replication system like
IBReplicator is complex system in its own right that, once configured and
running, is automated and transparent to all but the DBA who monitors
it. It's at the "high end" of the scale in its ability to meet
requirements. Custom replication systems fall at various points on the
scale between this and the low end (application-dependent).

Helen