Differences between working in a replicated and non-replicated database

Analysts see little difference in how they work in a replicated database. The main differences are for senior analysts who check for and review conflicts, and merge records, and for database designers who use iBase Designer.

Analysts

When a user edits or deletes a record, the updated or deleted record is merged with the publication database, and the Publisher replicates that change to the other subscription databases. The user is not aware of this process.

If another user is working on the same record when the change is replicated to their database, they are prevented from saving their changes to the record. They must click Cancel to close the dialog and then re-enter their changes. This is identical behavior to a non-replicated database, for example, if another user makes a change first.

Users see little difference when they work in a replicated database. From their point of view, the main difference is the need to consider who owns a record before they edit or delete it. To make this process easier, individual users should add their own contact details. See Checking the Ownership of Records for further details.

Note: If an analyst makes a change that results in a conflict, their change is overwritten if the change made by the other site merged with the Publisher first. The user going back to their records does not see their change and might want to re-enter it. However, before they continue they should review both the data and the record properties to find who changed it and when.

During data entry, users should always pay attention to warnings that concern duplicate values, and should always investigate the circumstances that produced the warning.

Database designers

Attention: Unless you are a security administrator, do not open a replicated database in iBase Designer while replication is configured in SQL Server.

After a database is being replicated, you are restricted to what you can do in iBase Designer with the publication and subscription databases. In particular, you cannot make any changes that affect the database schema, for example change the entity or link types, add new code lists, or assign semantic types. See What is a Schema Change? for further details.

However, you can do the following (although you might use iBase for most of these tasks):
  • Import and export data.
  • Update search indexes (these are not replicated).
  • Create database templates (these are not replicated unless you specifically upload them using the File Manager).
  • Define labeling schemes (these are not replicated and this can be done in iBase).
  • Add values to code lists (this can be done in iBase).
To make changes to the database schema, the SQL Server administrator must disable replication at all sites. This requires all fixed and disconnected Subscribers to be connected to the Publisher. Changing the schema of a replicated database is not a trivial task for either the iBase or SQL Server administrators. For more information, see Changing the Schema of a Replicated Database.
Note: Changes made to the database while replication is not configured are not replicated to the other sites when replication is reconfigured in SQL Server.

iBase database administrators

There are a number of differences between replicated and non-replicated databases that might affect day-to-day working, for example how you merge records, and restore and purge soft deleted records. However, the principal administrative task in a replicated database is to check regularly for conflicting changes to the entity and link data.

When there is a conflict:
  • All sites see the same data.
  • Users are not aware that an entity or link is in conflict, and work with the winning record until the outcome of the conflict is changed in the Conflict Viewer.
  • Users can modify and delete the "winning" record in the usual way.
  • Users in the publication database cannot remove the conflict by restoring a record using the Restore Deleted Records dialog (because this dialog cannot be displayed while any conflicts exist).

If a user at a subscriber site is working on a record while it is in conflict, for example editing it, and the record is changed and replicated as a result of reviewing it in the Conflict Viewer, that user is prevented from saving their work. However, this is identical behavior to a non-replicated database when another user saves their changes first.

There are a number of ways in which you might be able to improve how you use iBase to minimize the risk of conflicts occurring. This is important if you use the Merge Entities command as any conflicts that arise from merges cannot be handled by the Conflict Viewer.

iBase security administrators

When the security data is replicated, security administrators must implement a procedure to prevent the creation of duplicate user accounts. They are also responsible for checking that no duplicate groups or user accounts exist. Allowing users to log on with a duplicated user account and password can give one of those users access rights to which they are not entitled.