About non-transactional replication
Non-transactional replication does not assume that the source database and target database are connected through SQL Server networking. Non-transactional replication uses inbound/outbound queues and XML documents to transfer data or to pass application calls (remote procedure calls, or RPCs).
With non-transactional replication, the source database and the target database do not need to be on the same version of Mongoose. However, if you are using different versions, you might need to define XSL transformations, so that the data arrives at the target location in a usable format for that version. Transformations are required if something significant has changed from one version of the data source to the other, or the target database has more differences than just new nullable columns.
You can also use non-transactional replication to communicate with other applications, if transformations are provided. For more information, see the Infor Mongoose publication Integrating IDOs with External Applications.
Non-transactional replications are normally created to occur “immediately”—that is, updates are placed in the replication queue as soon as the Replicator service polling interval has elapsed. However, they can be created to occur at specified intervals—that is, updates are put in the queue when the time interval specified in the replication rule has elapsed. As soon as it reaches the queue, the data is then processed by the replication services. In practice, though, the immediate option is almost always the one used.
Data errors in non-transactional replication must be handled by the target database. The user at the source location can be unaware that a replication-related error occurred.
Non-transactional replication populates two tables:
- The "ShadowValues" table: This table contains the actual data values being replicated to the target location.
- The "ReplicatedRows3_mst" table: This table stores general data (schema, etc.) about the replication request.
You can review the contents of these tables, using the Replication Viewer form, before replication actually occurs. Once the replication process completes, these tables are cleared.