Progress has sent out a notification regarding an issue in versions before OpenEdge 11.7. We haven’t received any reports that an existing V803 to E905 customer has run into this issue and customers with large databases tend to split their databases into multiple areas for performance reasons before the point that this would be an issue so the potential impact of this bug to our customers is very small. The workaround is listed in the KB article that is linked below as a hotfix isn’t available for versions of OpenEdge before 10.2B. The errors in question would appear in the database log (e.g. c:\epicor\epicor905\db\mfgsys.lg). If there are any questions, please feel free to contact Epicor Support.
Attention Requested: Important Hotfix Notification
The Progress OpenEdge team would like to bring your attention to a potential issue that you may encounter within the OpenEdge database. The issue will only manifest in certain scenarios and will likely impact a very small subset of our customers. However, if left undetected, it may eventually result in a production database fail. To ensure this does not happen for any customer, we have documented the issue and have provided recommended next steps. Please carefully review the following information. If you believe that you may be at risk, please take the appropriate corrective actions provided below.
Note: If you are not directly responsible for your production OpenEdge database, please forward the following information to your Database Administrator or someone with similar responsibility.
What is the issue?
For very large OpenEdge databases, it is possible that there can be undetected index corruption if the index grows larger than can be referenced by a 32-bit variable.
What symptoms will I experience if this issue occurs in my database?
The index corruption will likely lead to one of the following errors:
• SYSTEM ERROR: Attempt to read block 0 which does not exist in area, database (210) (14648)
• SYSTEM ERROR: Index x (table-name,index-name): couldn’t find key recid nnnnnnnnn (8783)
In addition, the Index Fix (idxfix) utility is not able to locate the index corruption An Index Rebuild (idxbuild) may temporarily correct the issue, but the index corruption is very likely to occur again.
Finally, After Image (AI) files and OpenEdge Replication can propagate any index corruption.
Will my production database experience this issue?
You are vulnerable if the High-Water Mark (HWM) of the area containing the index is above 2 Gb. To determine your HWM, use prostrct statistics (prostrct statistics on areas containing indexes. If the number of active blocks listed by the prostrct statistics for an index area is greater than (2^31 / [area records per block]), the area is susceptible to this issue.
If you are on OpenEdge 11.7, the Index Check (idxcheck) utility has been enhanced to more quickly detect if this issue is present in your 11.7 database.
What should I do? [editted to reflect the option available to V803 to E905 customers]
Summary
As mentioned above, it is likely that only a very small percentage of OpenEdge customers are vulnerable. By disseminating this information widely, we want to make all customers aware of the potential issue and allow them to take appropriate action if necessary.
Progress apologizes for any issues or concerns that this problem may cause.
Please make use of the resources listed in this notice, and as always you can contact our Technical Support team if you need any further assistance. You can locate contact information at Global Phone Support - Progress.