Did this article resolve your question/issue?



Fixing Error 1124 on a Storage Area that holds only indexes versions post 10.1C04 10.2A02 10.2B

« Go Back


TitleFixing Error 1124 on a Storage Area that holds only indexes versions post 10.1C04 10.2A02 10.2B
URL Name000033538
Article Number000157736
EnvironmentProduct: OpenEdge
Version: 10.1C04, 10.2A02, 10.2A03, 10.2B, 11.x, 12.x
OS: All supported platforms
Question/Problem Description
Error 1124 running application code indicating database block corruption.
Error 1124 still appears after reboot, with the same dbkey values as before.
PROUTIL -C DBSCAN reports block corruption on the same dbkey values as the 1124 error.
The Storage Area specified by <num> contains only Indexes and no Tables or LOBS.
Steps to Reproduce
Clarifying Information
PROUTIL -C DBSCAN may also report additional corruption.
Error MessageSYSTEM ERROR: wrong dbkey in block. Found <dbkey>, should be <dbkey2> in area <num> (1124)
WARNING - indexmove not allowed with inactive index. (8575)
Defect/Enhancement Number
When an error 1124 occurs on a Storage Area that only contains indexes and no data, the following documents an alternative to dump and reload to fix the index block corruption.

Before going through the following steps to fix the problem, it cannot be stressed enough that a thorough hardware check should be carried out, as a persistent error 1124 is caused by pre-existing a hardware problems almost all of the time. Please refer to Article Determining the causes of System Error 1124 (wrong dbkey in block)

To fix corruption in an Index-only Storage Area:
  1. Verify the Storage Area with corrupt index blocks (which we will call "OldIndexes") contains only Indexes
  2. (Optionally) Move all the "OldIndexes" Storage Area extents with corrupt index blocks to a new location on disk.
  3. Delete all the index entries by re-setting the High Water Mark with PROUTIL -C TRUNCATE AREA
  4. Rebuild all the indexes in this Area with PROUTIL -C IDXBUILD, causing the index block headers to be reformatted as the indexes are created.

0.   Ensure an OS copy backup of the current Database areas before starting.

1.   Query to list all index names in the corrupted Storage Area.

The following ABL code warns if the Storage Area contains objects other than indexes, in which case the following steps in this fix cannot be applied as all the data in these tables will no longer be available! 
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!"
  FIND _Index WHERE _Index._Idx-Num = _StorageObject._Object-Number.
  FIND _File OF _Index.
  DISPLAY _File._File-name _Index._Index-name.

2.   (Optionally) Move the Storage Area to a new location. If a disk hardware problem is suspected then copy these files to a new disk.

Update the database structure file:
$   prostrct list <dbname> <dbname>.st

OS Copy the Storage Area extents to a new location.

Open the database structure file ( in a text editor and update the full path of the new file location  these extent files were copied to in the previous step.

Update the Database Control Area with the new file location:
$  prostrct repair <dbname> <dbname>.st

3.   Delete all the index entries by re-setting the High Water Mark

Truncate the before-image file
$  proutil <dbname> -C truncate bi

Truncate the corrupted Storage Area
$  echo y | proutil <dbname> -C truncate area "OldIndexes"

TRUNCATE AREA will list all the indexes contained in the area, which will be the same list as that produced by the ABL program above. Example:
The contents of index "CustNum" will be deleted.
Index "CustNum" was deactivated. (1515)

4.   Rebuild all the indexes in this Area with IDXBUILD

In OpenEdge 10 or later, indexes can be rebuilt "By Area" from the IDXBUILD choice list, in other words by this "OldIndexes" Storage Area 

The following ABL code will determine which indexes are de-activated at this time, then manually feed the index names by selecting "SOME" from the IDXBUILD choice list:
Note that when "_index_active = NO" this is purely from the AVM perspective. The "_StorageObject._Object-state = 1" identifies the list of indexes that require building from the database perspective.
FOR EACH _index, EACH _file OF _index WHERE _file-number > 0 AND NOT _file-name BEGINS "SYS": /* WHERE _index._active = YES : */
        FOR FIRST _StorageObject WHERE _Object-state = 1 AND _Object-number = _idx-num:
           DISP _file-name SKIP _index-name SKIP.

Once the idxbuild utility has completed, take a new PROBKUP of the database before starting for production.
Last Modified Date10/28/2020 5:06 PM
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.