Kbase P25221: Index on Table cannot be found, kmkinit -- idx not found. (131)
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
13/11/2008 |
|
Status: Verified
SYMPTOM(s):
Index on Table cannot be found, kmkinit -- idx not found. (131)
SYSTEM ERROR: kmkinit -- idx not found. (131)
Some tables in the database CAN be referenced
Removing NO-ERROR results in error 131
Some tables cannot be found
FIND FIRST NO-LOCK being used to reference table
Multiple databases being connected to
Table being referenced is only in one of the databases
CONNECT statement being called from procedure before referencing table
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Product Family
CAUSE:
This error typically shows up when changed indexes are being updated. Index keys are being checked for validity and created if needed throughout this process. We are checking for the type of update being peformed, such as SQL for example, and making the necessary changes to the index. (creates, updates, deletes etc.)
When we get to the stage when we are adding a new index entry, we are scanning through all of the records validating all the keys. If we encounter a duplicate key at this point, an error message will be sent out and the index would have to be repaired, preferably with idxfix.
If we don't have a problem with the index key validation process, we then assign an initialized status to the index. This is the point where we can see the
SYSTEM ERROR: kmkinit -- idx not found. (131).
Before kmkinit can assign a status to the index,we must go through the index manager to find the index. If we don't find it, then we see the error.
FIX:
In most cases, and index rebuild will eliminate this error and has been very effective in doing so.
A potential cause of the problem may be an error in the process of modifying, creating or deleting an index. However, the proutil -C idxbuild should get around the problem.
If not, then compiling with the XREF option, then examining the usage as reported in the SEARCH lines of the XREF output file would be a useful first exercise. Consider using the -rereadnolock startup parameter to ensure that a fresh copy of the record is being read if NO-LOCK is being used or replace the NO-LOCK with SHARE-LOCK.