For SQL Server administrators

When you set up iBase database replication in SQL Server Enterprise Manager or Management Studio, keep your replication setup as simple as possible and avoid using SQL Server replication features that increase the complexity of the setup.

iBase database replication uses SQL Server merge replication to distribute data from the Publisher to Subscribers, allowing the Publisher and Subscribers to make updates, and then to replicate the updates between sites. However, iBase database replication is unlike SQL Server merge replication in that Subscribers must always be connected to their Publisher - it is not suitable for disconnected users.

The setup is described in more detail in the following information.

iBase supports the following features of SQL Server replication:
  • Merge replication.
  • Servers running SQL Server 2005 or SQL Server 2008 (the replicated iBase system must not contain a combination of these).
  • Native SQL Server format for the initial snapshots.
  • Subscribers that synchronize with the Publisher— the Subscribers can be either fixed or disconnected.
  • Subscribers that receive subscription data from the Publisher.

For more information, see Supported Publication Options and Supported Subscription Options.

Prerequisites

All servers that are to be configured for merge replication must be set to the same time.

Unsupported features

iBase does not support:
  • Anonymous pull subscriptions - publications that allow anonymous pull subscriptions are invalid.
  • On demand synchronization - data from Subscribers must be synchronized at a regular interval, for example a polling interval for the Merge Agent of 1 second for the publication that contains the entity and link records. You can select a different interval for the publications that contain the security and audit data.
  • Subscribers that receive subscription data from another Subscriber rather than from the central Publisher (republishing).
  • Subscribers that synchronize with another Subscriber rather than with the Publisher (an alternate synchronization partner).
  • Column level conflict resolution in iBase databases all updates are handled at row level. This is because a change to a single column changes the modification date and user, which results in a conflict occurring.
  • Data filtering of either columns or rows when you add a table to an article, you must select all the columns and rows.
  • Dynamic data filtering (you cannot filter the data that you provide for different Subscribers).
  • Publishing via the Internet.
  • Custom resolvers iBase has its own Conflict Viewer, which runs as part of iBase and requires that the first change to merge with the Publisher wins the conflict. The Conflict Viewer allows iBase users to review the conflicts and change the outcome if required.