Subscribing to entity and link publications

Create push or named pull subscriptions for an entity and link database.

About this task

Note: If you are creating a subscription for the first time to a database transferred to the subscriber site as a backup or attachable subscription database, follow the instructions in:
In this situation,
  • Subscriptions for Restored Databases

    If you are recreating a subscription that has been dropped, follow the instructions in Recreating Publications and Subscriptions.

    Before you can start, the iBase administrator should have:

  • Created a database for the entity and link data on the Subscriber
  • Told you if the database is to be read-only because this affects how you set up the Merge Agent

Unless specified below, you should always accept the default options when you create the subscription.

Procedure

  1. Start a new subscription of the required type. The subscription should be as follows:
    OptionDescription
    Publication The database that contains the iBase entity and link data at the Publisher.
    Subscription database The existing entity and link database at the Subscriber.
    Select the following options for the subscription:
    • The Subscriber does not have the schema and data and should therefore be initialized.
    • Depending on the subscription type, set the Merge Agent to initialize the subscription immediately (optional).
    • The Merge Agent should continuously check for updates.
    • Use the Publisher as a proxy for the Subscriber when resolving conflicts (described as First to Publisher Wins).
    • The subscription is a client subscription type
  2. Set the Merge Agent for the Subscriber to run at the required frequency, for example a polling interval of 1 second.
    For more information, see Merge agent for the entity and link database.
    Note: If the iBase database at this Subscriber is read-only, configure the Merge Agent to prevent any uploads to the Publisher. For more information, see Merge agent for a read-only database.
  3. Verify that the snapshot has been applied by checking that a rowguid column exists in one of the user tables selected for the article. If this column is missing, check that the snapshot has been applied.
  4. Test that replication is working correctly for the new subscription. Use one of the user-defined tables:
    1. At the Publisher, in one of the user tables (table names do not start with an underscore), change the data in one of the columns for a row. For a new database, carry out this test on the _GlobalConfiguration table and change the version number but take care to change it back to its original value.
    2. After the change is replicated, check the corresponding table at the Subscriber.
    3. At the Subscriber, change the column back to its original value.
    4. After the change is replicated, check the table at the Publisher. If the Subscriber is supposed to be read-only, and the change is merged at the Publisher, check the setting of the Merge Agent.
    5. If the Subscriber is read-only, change the data at the Publisher back to its initial value.
  5. Restrict access to the tables in the SQL Server database. See the Administration Center document Managing Access Control, for details. The information in this document applies to all types of iBase database.
  6. Back up the databases.
    For more information, see:
  7. Tell the iBase administrator that the security data at the Subscriber is configured for replication.