IDXCHECK fails against the replication target database

IDXCHECK fails against a replication enabled target database with errors 915 8783
IDXCHECK does not fail against the replication enabled source database with the same Lock Table (-L) value

PROUTIL IDXCHECK is a supported utility to run against both a source and target replication enabled database.

Any user or utility connecting to a target database, apart from the Replication Agent under limited scenarios, is not expected to acquire record locks. IDXCHECK does not take into account the ERO state of the target database when it unlocks the database index object it is scanning, which leads to a Lock Table Overflow condition.

Upgrade to OpenEdge 11.7.5, 12.1.0 or later, where IDXCHECK no longer acquires locks when run against an OpenEdge Replication target database.

It is advisable to first assure all updates from the source have been applied and stop replication processing before running IDXCHECK. Switch the current BUSY ai extent then use DSRUTIL -C apply extent to update the target with the transaction notes in locked extents:

• How to manually apply a LOCKED AI extent to the target database?   

An online IDXCHECK may still report false errors about indexes or records because it runs without locks. This needs to be confirmed against the source database without -NL and with -lkwtmo for that specific table.index:

Run IDXCHECK with the no lock parameter (-NL) to prevent acquiring record locks during the index scan, to avoid the lock table overflow:

Progress Article: 

What are the implications of the online IDXCHECK locking options?