Salesforce

Error 8783 cannot be fixed either by running IDXFIX (Option 3) or IDXFIX (option 6) for a database with RECID field datatype

« Go Back

Information

 
TitleError 8783 cannot be fixed either by running IDXFIX (Option 3) or IDXFIX (option 6) for a database with RECID field datatype
URL NameSystem-Error-8783-could-not-be-fixed-either-by-running-IDXFIX-option-3-or-IDXFIX-option-6-for-a-database-with-RECID-field-datatype
Article Number000118561
EnvironmentProduct: OpenEdge
Version: 11.x
OS: All supported platforms
Question/Problem Description
Error 8783 on indexes with a RECID key field
Error 8783 could not be fixed by either running IDXFIX (option 3) or IDXFIX (option 6) to delete a specified RECID.
 
Steps to Reproduce
Clarifying Information
The data type of database field is RECID.
When the record is created, the recid value in the 64-bit range and the field is part of an index key

Running IDXFIX Option 3 (with both validate and fix) on a specified RECID, within table and index and IDXFIX option 6 to delete a specified RECID have not fixed the error 8783.
 
Dropping the entire table and creating it again temporarily address the issue but after some time the same error 8783 occurs again.
 
 
Error MessageSYSTEM ERROR: Index<index-num> (<owner-name>.<table-name>, <index-name>): couldn't find key <key> RECID <DBKEY>. (8783)
Defect NumberDefect PSC00338984
Enhancement Number
Cause
When the record is created with a recid value in the 64-bit range and the field is part of an index key, the routine that creates the index key for the datatype recid creates the index key correctly.

The routine used by index utilities, (idxcheck, idxfix, idxbuild, idxactivate) processes RECID datatype fields as an INTEGER field when validating or building keys. This results in false negatives when index verification is used and index corruption when index build utilities are used.

For example:
  • IDXCHECK reports false negatives before indexes are built by utilities (reports corruption when there is no index corruption)
  • IDXCHECK reports false positives after indexes are built by utilities (does not report corruption, when there is)
Resolution
Upgrade to OpenEdge 11.7.2, 11.6.4 or later when available.
Workaround
First determine the largest current RECID value for a tables with a RECID Data Type Field that is part of an index:
      
DEFINE VARIABLE r1 AS RECID NO-UNDO.
DEFINE VARIABLE r2 AS RECID NO-UNDO.

FOR EACH <tablename> NO-LOCK:
    r2 = RECID(<tablename>).
        IF (r2 > r1) OR (r1 = ?) THEN
        r1 = r2. 
END.

MESSAGE r1 VIEW-AS ALERT-BOX.
For further information refer to Article  How to determine if the value returned by the RECID function is about to reach 2 billion  

Option 1:  Consider using the INT64 datatype for the affected field/fields instead of RECID datatype. Refer to Article: Option 2:  If indexes have been built for indexes with RECID data type field keys in the 64-bit range:
  • Re-instate the table with an ASCII dump and load,
  • Ignore 8783 errors reported by index utilities against these indexes.
 
 
Notes
Keyword Phrase
Last Modified Date12/30/2020 8:10 AM

Powered by