Consultor Eletrônico

Status: Verified

SYMPTOM(s):

Idxfix run on/offline OPTION 3, report and fix, deletes, then adds the same entries back

The key index deleted in message 8829 is the same that is added back in message 8827

Index <index number> (<owner name>.<table name>, <index name>): Found invalid key <key value> recid <record identifier>. (8829)

Index <index name> (<owner name>.<table name>, <index name>): Added key <index value> recid <record identifier>. (8827)

The errors reported by idxfix OPTION 2 only start appearing after a certain load of records that need scanning {13000 - 13500 records)

Idxfix run on/offline OPTION 6 delete record and indexes reported by Option 2, does not delete all associated indexes of the record deleted and introduces further corruption.

When the entire table is scanned by idxfix in smaller batches, no errors are found

All the records in the table can be read by this WORD index, while the idxfix is reporting errors.

Only applies to WORD index entries

FACT(s) (Environment):

Progress 9.1x
All Supported Operating Systems

CAUSE:

Bug# 20040526-029

CAUSE:

This issue identified that not only is the idxfix operation consuming too much memory when checking word indexes, but that it also might delete keys of word indexes.

This only affects option 2 of idxfix, option 1 works as expected. Since Option 3 is a combination of option 2 and option 1, the index keys are first deleted by option 2 and then added back by option 1, so the index is fine before and after option 3.

Option 2 alone can cause incorrect deletion of word index keys. This bug is related to the number of records against which the idxfix operation is running, so deleting the specified record does not fix the problem, that's why option 6 doesn't work in this case.

FIX:

This issue has been addressed in Progress 9.1E and Open Edge 10.0B

One workaround is to run idxfix with option 1 to add keys back after running option 2 alone,

Another workaround is to run idxbuild on this word index.