Replication: Frequently Asked Questions

Advantage Concepts

Why isn’t my data being replicated?

 

How can I identify the target record of a failed update?

If a replication update fails, locate the entry in the error log (ads_err.adt). Replication errors have error class 7600. The More_Info field will contain the SQL statement of the failed update. It will also contain the subscription name, table name, and the EntryID (primary key) of the replication queue entry that failed. It also logs the physical record number of the source table.

Note There is no guarantee that the record numbers match in the source and target.

Finally, if you have the subscription option enabled to log data with replication failures, the searchable field information will be logged with the failed SQL statement. This should help identify the record.

 

How is replication different from the online backup functionality?

While there are some conceptual similarities between replication and backup functionality, they are implemented with very different solutions in mind. The backup functionality is intended for making backups of your data for subsequent restore operations. Replication is used to keep two or more live databases logically consistent with each other.

 

Why do connections still exist after I have disconnected my application?

Replication uses connection pooling for both internal connections and external connections to the target. The lifetime of the entries in the pool is approximately one minute. If the replication queue is empty, these connections should close automatically after a short time. If there are entries in the replication queue that are being processed, the connections will stay active until the queue is empty.

 

What happens if I restructure the replication queue?

It will cause replication failures. The replication queue is created with administrator privileges to prevent casual modifications. It may be necessary to remove entries from the replication queue at times, but you should not restructure the table. If the table has been corrupted beyond repair, it is possible to delete the physical replication queue file; Advantage will re-create the replication queue file on its next use.

 

What will happen if I delete the replication queue from the hard drive?

The replication queue is implemented as an Advantage ADT table. If you delete the physical table and there are unprocessed replication updates in it, those updates will not be replicated. If the table is empty, it will be created again the next time a replication update occurs.

 

Will replication cause performance degradation?

Some extra processing is required, but there should be very little performance degradation due to replication. When an update for a client application occurs, the update is stored in the replication queue. That is the primary cost of replication that may affect a user application. The bulk of the replication work is performed asynchronously by other threads and, thus, reduces the direct impact on existing applications.

 

What permissions are needed for replication to work?

No specific permissions are needed at the source database. All updates to replicated tables are replicated regardless of the permissions of the user making the update. The replication user (the username and password that are defined in the subscription) must have INSERT, UPDATE, and DELETE permissions at the target database in order to make the necessary updates (assuming that all of those operations can occur at the source). In addition, the replication user must have SELECT (READ) permissions on the identification columns at the target database in order to be able to locate the record that is to be updated.

 

Do the source and target tables need to be identical in format?

The names of the fields that are replicated must be the same in both the source and target tables. In addition, the types must be compatible. For example, you cannot replicate an integer field in the source to a text field in the target.

Beginning with version 8.1, however, it is no longer required that the source and target tables have identical structures. The target table can have a subset of the columns that are in the source table. For this to work, you must specify a vertical filter on the source table. You can specify the list of columns to include or exclude from replication. Define the vertical filter using Advantage Data Architect as part of the publication definition. You can also define a vertical filter programmatically with the Advantage Client Engine API AdsDDSetArticleProperty or through the stored procedure sp_ModifyArticleProperty.

 

Does replication guarantee that source and target tables are always in sync?

No. Advantage replication simply distributes updates from the source database to the target database(s). If updates made to the target are not replicated to the source, the tables will be out of sync. Advantage replication does not perform any synchronization actions.

 

When two databases are replicating to one another, can one of them have its own set of triggers to do a task unique to that server?

Yes. Each database can have a unique set of CONFLICT triggers.

 

How long will it take after bringing up the target server before the replication updates occur?

If there are pending replication updates at the source database, it will periodically attempt to connect to the target server to perform the updates. The time between attempts varies up to one hour but will occur immediately if an update is made to the source.

Note If the source server has pending replication updates and has been shut down, it requires someone to log in to the database before replication will occur.

 

What happens if the target record is modified prior to a modification of the same record at the source?

It depends on the replication definition. For each table being replicated, you specify how the record is located (identified) at the target. You can choose to use all searchable (non-memo/blob) fields or specify some subset of fields (e.g., primary key). If you are choosing to use all fields to identify a row, then the replication update will fail because it will not be able to find the record. If you are using, for example, the primary key, then the update attempt will be able to find the record (assuming the primary key was not changed). If there is a CONFLICT trigger, then it will fire the trigger, and it is up to the trigger to make the decision about what to do. If there is no CONFLICT trigger, then the update will simply succeed and will overwrite the previous change.

 

How can I specify which part of my table to replicate?

You can control what data is replicated by defining both horizontal and vertical filters on a table. A horizontal filter is an expression equivalent to a WHERE clause in an SQL statement that defines whether or not a modified or new record will be replicated. A vertical filter defines which columns of the table will be replicated.