When changes are made to tables MAKEDB is supposed to check if the changes would affect tables containing data, and if the structure of an index on a table containing data is changed it should force a reorganisation.
In fact there is a long standing bug in this code, which can cause a reorganisation to be forced when it should not be, or vice-versa. The same problem can also arise when making changes to a database using copydb or the structure transfer option of recastdb.
Currently MAKEDB still forces a complete REORGDB when indexes to tables containing data are changed. MAKEDB will shortly be enhanced to allow a selective reorganisation in this case.
21 Aug 2002 A different bug, but with a similar effect has recently come to light in COPYDB. When a database structure file is posted to a database COPYDB is supposed to preserve certain settings such as whether a secondary index that has been recently turned on has had an up to date index built yet. Unfortunately this was not done properly so that the flag could become unset. This would mean that a subsequent DBCHECK could fail indicating a range of problems with the index, if the index had been previously turned on and built, then turned off, then turned on again after changes to the table being indexed. This has been fixed in the updated download.
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.
Please go to page e4000026 for the download and instructions.
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.