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(DSO) should be deleted by DSO.

The limitation of logging ARERR 302 during distributed deletes is that when DSO is used to synchronize data between the main server and a backup server, insignificant ARERR 302s are logged.

Example

The following example shows how ARERR 302s are logged:

  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 select System > General > Server Information.
  2. In the AR System Administration: Server Information form, click the DSO tab.
  3. 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.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*