Logging the ARERR 302 error during distributed deletes

By default, AR System server error 302 (entry does not exist in database) is always logged in the arerror.log file when distributed deletes are performed except when the DSO Error Retry Option is set to 2 (see Error Retry Option).

The advantage of logging ARERR 302 during distributed deletes is that it helps detect errors in workflow logic. For example, in a distributed server environment, requests created by Distributed Server Option should be deleted by Distributed Server Option.

The disadvantage of logging ARERR 302 during distributed deletes is that when Distributed Server Option is used to synchronize data between a main server and a backup server, meaningless ARERR 302s are logged as follows:

  1. On the main server, Filter A performs a distributed delete, which deletes Request B in Form C on the main server and on the backup server.
  2. On the backup server, corresponding Filter A tries to perform the same distributed delete, but Request B in Form C no longer exists on either server.
  3. Because the target request was not found, ARERR 302 is entered into the backup server's arerror.log file. Logging too many of these errors can make it difficult to analyze the log because you must determine whether each ARERR 302 entry was generated during a distributed delete or for a valid issue.

To prevent ARERR 302 from being logged during distributed deletes

  1. In a browser, open the AR System Administration Console, and click System > General > Server Information.
  2. In the AR System Administration: Server Information form, click the DSO tab.
  3. On the tab, select Suppress No Such Entry Error for Distributed Delete.

  4. Click Apply.

    Warning

    When this option is selected, ARERR 302 entries generated by valid problems with distributed delete operations might also be omitted from the log.