Status: Unverified
SYMPTOM(s):
Error 1124 running the application:
SYSTEM ERROR: wrong dbkey in block. Found <dbkey>, should be <dbkey2> in area <num> (1124)
The storage area specified by <num> contains only indexes and no tables.
1124 still appears after reboot, with the same dbkey values as before.
CAUSE:
Database is corrupted on disc.
FIX:
Because error 1124 occurs on a storage area that only contains indexes, and no data, there is one alternative to dump and reload.
Before going through the steps to fix the problem, it cannot be stressed enough that a thorough hardware check should be carried out, as error 1124 is most of the times caused by a hardware problems. Please see Solution P5286 for further details.
In a nutshell, the following will help you migrate the indexes from the corrupted storage area (which we will call "OldIndexes") to a brand new one (which we will call "NewIndexes"). The corrupted storage area will then be dropped.
- Add a new storage area via prostrct add.
- Run the following 4GL program to find out which indexes reside in the corrupted storage ara.
FIND _area WHERE _Area._Area-Name = "OldIndexes".
FOR EACH _StorageObject WHERE _StorageObject._Area-number = _Area._Area-number:
IF _StorageObject._Object-Type <> 2 THEN DO:
MESSAGE "Storage area" _Area._Area-Name "does not only store indexes!"
VIEW-AS ALERT-BOX INFO BUTTONS OK.
RETURN.
END.
FIND _Index WHERE _Index._Idx-Num = _StorageObject._Object-Number.
FIND _File OF _Index.
DISPLAY _File._File-name _Index._Index-name.
END.
This program warns you in case the corrupted storage area contains objects other than indexes, in which case this fix cannot be applied.
- Truncate the corrupted area:
proutil <dbname> -C truncate area "OldIndexes"
The utility will list the indexes contained in the area, which will be the same list as that produced by the 4GL program above.
When proutil asks whether you are sure that you want to truncate the are, reply Y plus the Enter key.
- Move each index listed by the 4GL program above to area "NewIndexes"; for example:
proutil <dbname> -C idxmove <tableName>.<indexName> "NewIndexes"
- Once this is done, truncate the "OldIndexes" area again, with the same "proutil -C truncate area" command as before.
This time, though, proutil should not list any indexes at all, because the indexes that used to be in area "OldIndexes" have all been moved to area "NewIndexes" via proutil -C idxmove.
Like before, when proutil asks whether you are sure that you want to truncate the are, reply Y plus the Enter key.
- Now truncate the before-image:
proutil <dbname> -C truncate bi
- At this point you can proceed to remove the area "OldIndexes" altogether, by running:
prostrct remove <dbname> d "OldIndexes"
This operation will have to be repeated once for each data extent that makes up area "OldIndexes".
- In order that your structure file (dbname.st) is up-to-date, run:
prostrct list <dbname>
- Your indexes are now in area "NewIndexes", while the old, corrupted area has been dropped. You need now to re-activate those indexes, so please run:
proutil <dbname> -C idxbuild
If you are running version 9 or earlier, you will have to choose to rebuild Some Indexes, and then manually feed the index names.
If you are running OpenEdge 10 or later, you can select to rebuild indexes By Area, which is quicker and less error-prone.
Once the idxbuild utility has completed, your database is ready for production.