Hi,
This indicate a Index corruption in your database KB P20191 or P9756 (Both in ProKB.
Status: Verified
FACT(s) (Environment):
Progress 8.2x
Progress 8.3x
Progress 9.x
SYMPTOM(s):
Attempts to delete records indicate the record can not be deleted.
Index <indexname> in <tablename> for recid <recid> could not be
deleted. (1422)
Queries to the table return incorrect records.
Any query by index <x> fails whereas a query by index <y> succeeds.
CAUSE:
Currently no known cause has been attributed to this index corruption
problem.
Queries to the table return incorrect records or indicate the record
can not be deleted.
The index note is pointing to a different record.
FIX:
1) Export the data from the record by recid.
(This allows the data to be reviewed for accuracy and uniqueness. It
also allows the record to be inserted back into the database if
desired.)
example:
OUTPUT TO <filename>.
FOR EACH <tablename> WHERE RECID(<tablename>) = <recid of bad record>.
DISPLAY <tablename>.
OUTPUT CLOSE.
2) Remove the record from the database with the idxfix tool:
example:
proutil <dbname> -C idxfix
Enter selection:
6
Type the recid to delete.
<recid>
Type the area for the recid(s).
"<area name>"
Is this correct?
y
The problem could be due to a not unique value for field(s) part of a
unique index. This can be checked by using the record's information
in step1 and different queries searching for records that would have
the same field data for the index fields that are unique. From this
point, you will be able to confirm duplicity and decide to either
delete all similar cases of duplicates or to modify the index
definition to stop this happening again. ** It is only when attempting
to delete that particular record, that the 1422 will return in the
database log file. ** To investigate further the error, you could
check if there are other records within that table which have problem
with the same index.
You can either run "idxbuild" (off-line) or "idxfix" option 3.
Status: Verified
FACT(s) (Environment):
Progress 9.1C
Progress 9.1D
Progress 9.1E
OpenEdge 10.0A
OpenEdge 10.0B
Progress 9.1x
SYMPTOM(s):
Error 1422 trying to update a record
SYSTEM ERROR: Index in for recid could not be deleted. (1422)
Using -lbimod set to 2
The record has been updated in a sub-sub-transaction (level 3 of
transaction)
A sub-transaction (level 2) rollback tried to restore the original
content of the record
The main transaction is committed
If the main transaction is rolled back the problem does not occur
If the UNDO level-2 from the level-3 the problem does not occur
Error 1422 happens in the next attempt to update the record
Happens to any 4GL client including DataServers
CAUSE:
Bug# 20041125-002
CAUSE:
There is a database corruption cause by the 4GL core client when
handling specific logic with embedded transactions.
When code that contains embedded transactions of at least 3 levels --
1 for the database non-lbi, and at least 2 within the lbi level --
updated a record in a sub-sub-transaction (level 3 of transaction) and
the sub-transaction (level 2) rollback tries to restore the original
content of the record, causing an inconsistency in the records that
have wanted old values in some fields and bad new values failed to be
roll back in some other fields. When index keys that were are
correctly rolled back gets out of synch with their related fields and
the database record becomes corrupted.
Note that On OpenEdge 10.0B the new default value for -lbimod was
changed to 2.
FIX:
Choose one of the following:
1) Upgrade to Progress 9.1E01 or later.
2) Upgrade to OpenEdge 10.0B02 or later.
3) As a workaround, use startup parameter -lbimod 0 for the client
sessions.
This parameter should be used for ALL types of clients (GUI Client,
TTY clients, batch jobs, AppServer, WebSpeed...) if the same offending
Logic procedures are used.
In both cases I would consult Progress Support.
Regards Ole
