How iBase uses replication

Replication is not a feature of iBase itself. To replicate an iBase database, your SQL Server administrator uses functionality within Microsoft SQL Server. However, in iBase you can prepare the databases for replication, and manage the databases after replication is configured in SQL Server.

Note: iBase uses Microsoft SQL Server merge replication in its simplest form. For information on supported configurations, see Overview of Supported SQL Replication Features.

Database configuration

iBase entity and link records, security records, and audit log are held in separate SQL Server databases, and each database is replicated separately. Replicating the audit log is optional. You cannot replicate Microsoft Access databases.

An iBase database that is set up for replication requires the following properties:
  • A database identifier that is unique across all the replicated databases. The database and the security file for a site can have the same database identifier (site identifier).
  • Soft delete, which is required by the iBase Conflict Viewer. Using the Conflict Viewer, users can review the way in which the conflicts between entities and links are resolved and can undo the change in order to select a different outcome.
The databases at the subscriber sites can be read-only. They receive updates from the Publisher but users are not able to make any changes.
Note: The maximum length of database and security file names is 119 characters. For more information, see Before creating any iBase databases.

Publishers and subscribers in an iBase system

One server must be selected as the Publisher, and the iBase database on this server is the publication database— the central database that provides the initial data for the other sites, and receives and sends updates from the databases at these sites.

The database that you select as the publication database:
  • Is used to detect and resolve conflicts.
  • Is the only database in which records can be restored, purged, and merged.
  • Provides the security file that will be used at all the sites involved in replication.
The subscription databases are identical to the publication database in terms of the entity and link data. Filtering of data (for example, by SQL Server) is not supported. However, each database can have its own report definitions, queries, import specifications, Text Chart templates.
Subscription databases can be administered centrally if you are able to log on remotely to the servers on which replication is running. Conflict resolution is always done centrally at the Publisher.
Note: Only one site should change the schema of a replicated database in iBase Designer, however the site might be either a publisher or a subscriber site. Regardless of which site the changes are made, there is a procedure that must be followed.

The security file in a replicated database

With a replicated security file, any iBase security administrator can add, delete, or update user groups and users, and the new user data is merged with the security file at the Publisher and then replicated to the security files at the Subscribers. Any duplicate user or group names are detected and a security administrator, working at any site, can correct any duplicates that might occur.

You should replicate the security file. You can only replicate a security file that you upsized to SQL Server.

Attention: If you use iBase with Extended Access Control, then it is essential to replicate the security file and failure to do so undermines the additional security provided by Extended Access Control.

For more information, see How Security Works in a Replicated Database.

Working on entity and link records

Any user given the correct permissions can log on to their local database, whether at the publisher or a subscriber site, and add, modify, or delete records. Changes that are made at fixed Subscribers are quickly merged with the data held in the publication database (if the user is working at one of the subscriber sites) and the changes are quickly replicated to the other sites so that all sites see the same data. In SQL Server, a separate merge process for each Subscriber uploads local changes to the Publisher and downloads all the changes made at or received by the Publisher. For a disconnected Subscriber, such as a laptop, merging, and replication can only occur when the Subscriber is on the network and connected to the Publisher.

For fixed Subscribers, merging and replication should be quick because the merge processes run continuously, and the frequency with which the processes run generally prevent any conflicting changes from occurring. In the unlikely event that a conflict does occur, SQL Server automatically resolves the conflict in favor of the Publisher and then the Subscriber who merged first. There is an iBase Conflict Viewer available in the publication database to review these conflicts and, if required, change how they were resolved.

For fixed Subscribers, conflicts are most likely to occur after a problem with a communication link between the publisher and one of the subscriber sites is rectified (there are no conflicts while the link is down). For disconnected Subscribers, conflicts can occur after connecting with the Publisher and merging their changes into the publication databases.

For more information, see Conflicts and How They Occur.

The audit log in a replicated database

You can choose to replicate the audit log to maintain an audit trail that covers all the replicated databases and security files. You can filter the audit log to view activity at just one site or for the whole organization.

Note: The facility to control who can view the audit log generated by users that work on sensitive data requires you to replicate the security file.

For more information, see How the Audit Log Works in a Replicated Database.