If a program updates or deletes records that it has locked and it is subsequently necessary to run DBRECOV then the database may be corrupt afterwards. The cause of this problem is that the database manager writes the record header to the rollback file when locking records, but not the whole record. When the record is subsequently updated the record is not always written to the rollback file again because locking updates the timestamp, and depending on what has happened previously this may or may not cause the datbase manager to believe the record is already in the rollback file.
If the datafile is updated but there is then a crash before the rollback log is flushed then the database will be corrupt after DBRECOV.
We are currently testing a fix for this problem. Until it is available you are recommended always to run DBCHECK -checksumfail -local after DBRECOV and to recover the database from a backup if necessary.
Where the version affected is given as 4.5xx or 4.6xx, all versions of DP4 issued prior to the date of the fix are potentially affected. Where a specific version number is given the problem was introduced by that release and prior releases are unaffected. If a patch release number is also specified (in parentheses) , the fault was introduced at that specific patch level.
4.523 (4)/4.619 (4) DP4SRVR.W32
Due to limitations on available web space downloadable fixes are only available for the most commonly used environments, and may not be separately available in both 4.5xx and 4.6xx flavours. If a file you require is not available you can ask us to e-mail it to you.