Common replication solutions

Problem: System performance is slow and you suspect replication may be causing this.

Solution: Check these areas:

(on-premises only) Use the stored procedure sp_spaceused (in the Master database) to determine which tables consume a lot of space.
If there are _all tables (that is, replicated data) that contain very large numbers of records, then make sure you are not replicating unnecessary data.
See the Replication Categories chapter in the Infor SyteLine Multi-Site Planning Guide, particularly the information about replicating financial data.
Also look at the descriptions of how the tables in each category are used. If your large _all tables are used only for reports that you rarely or never require, you might be able to remove that object from the category.
Before you make changes to replication categories, seriously consider requesting help from your Infor SyteLine provider or Infor Consulting Services.
See also the information on improving system performance in the Infor SyteLine Administration Guide.

Problem: Replication failure due to SQL Linked Server error

(on-premises only) If your system returns an error like one of these, the local server probably no longer has a link to itself:

Server ’servername' is not configured for Data Access. Distributed Transaction Completed. Either enlist this session in a new transaction or the NULL transaction.
New transaction cannot enlist in the specified transaction coordinator.
The operation could not be performed because the OLE provider 'SQLOLEDB' was unable to begin a distributed transaction.

Solution: To fix this problem, run these SQL commands on the application database:


exec sp_addserver servername, LOCAL  

-- restart SQL Server.

EXEC sp_serveroption 'servername', 'Data Access', 'True'

Replace servername with the name of the local server.

Problem: Invalid Column name UF_`xxxx`

(on-premises only) If your system returns an error message similar to this during replication, you may have user extended tables (UETs) set up in one site but not in another, in separate databases.

Solution: You must have identical schemas in all sites to replicate data.

If one site contains UET modifications to a table, but the same table in another site does not contain those modifications, errors probably will be generated during replication of that table’s data from one site to the other.

For that reason, before you replicate data between sites, you should copy any UET schema changes to all sites involved in the replication. A stored procedure, ExportUETClassSp, assists in handling this process.

Problem: Outbound BODs are not being sent from the ERP to another system

Solution: Follow these steps to determine the cause:

Does the BOD appear in the Replication Document Outbox?
(BODs are saved in the outbox after processing only if the BOD service is configured to not delete them.)
If yes, continue to the next step.
(cloud only) If no, then contact Infor Support.
on-premises only) If no, then do this:
1. If this is a multi-site system, verify that you are checking the outbox on a site that is defined in the Replicator/Inbound Bus Configurations area in the Service Configuration Manager utility.
2. From the SyteLine utility server, run the LogMonitor utility.
3. In the SyteLine application, perform the processing that should send the BOD. (See the Replication Document Outbound Cross References form for a list of the application events that generate the BOD.)
4. In the LogMonitor utility, look for ReplQListener log information that might indicate an error in the BOD processing.
Is the Processed check box selected?
If yes, the BOD was picked up by the BOD service. Check in the ION application for details.
If no, then there is a problem that is preventing the BOD service from picking up the message. Either the service is not running, or the configuration and deployment of the sending/receiving applications is not set up properly in the receiving application(s).

Problem: Inbound BODs are not being received or processed by the ERP

Solution: Follow these steps to determine the cause:

Does the BOD appear in the Replication Document Inbox?
(If there are many documents in the inbox, it can be difficult to find the BOD because currently you cannot filter by BOD name.)
If yes, continue to the next step.
If no, then something prevented it from being delivered by the BOD service:
1. (on-premises only) If this is a multi-site system, verify that you are looking at the inbox on a site that is defined in the Replicator/Inbound Bus Configurations area in the Service Configuration Manager.
2. (on-premises only) Check the BOD service logs to find failed message transmissions or information about why the failure occurred.
3. (on-premises only) Check whether the BOD service is running.
4. Check whether the configuration and deployment of the sending/receiving applications is set up properly. See the appropriate integration guide for more information.
Is the Processed check box selected?
If yes, and the expected information does not appear in the appropriate SyteLine form or table, then there was an error in processing. Check the Replication Document Outbox for a Confirmation BOD. A confirmation BOD indicates an error.
(on-premises only) Check these areas to determine the cause of the error:
- Windows application event viewer
- LogMonitor utility on the utility server, if it is running
If no, then either the Infor Framework Inbound Bus Service is not running, or it is still working through previous messages.

Problem: After adding a site in a different database, replication is not working

(on-premises only) If all sites were previously in the same application database, and you add a site in a different application database, you must regenerate views and replication triggers, and repopulate _all tables.

Solution: Follow these steps in one site in each application database:

In the Trigger Management form, leave the fields blank and click Generate to regenerate table triggers. (This is not related to replication, but it must be done after you add a new site in another database.)
If any new replication rules were set up to/from the new site, open the Replication Management form and click Regenerate Replication Triggers.
In the View Management form, leave the fields blank and click Generate to regenerate views over tables.
Restart the replication services on the utility server.
In the Update _All Tables form, select all tables, set Site to the current site and click Repopulate.
This step must be performed at every site and entity.

Problem: Error occurs in the Replication Document Manual Request Utility due to timeout

If you receive either of these errors during generation of BODs through the Replication Document Manual Request utility, then transactions are taking longer to run than the timeout values set in SyteLine or other related applications and services.


Exception from load collection: Error processing an IDO request 

(Protocol=Http, URL=http://servername/IDORequestService/RequestService.aspx): 

The remote server returned an error: (500) Internal Server Error.

BOD generation errors