Ron Seybold, in the 3000 NewsWire Online Extra, April issue update, writes:
 
snip....
>Finally, Dennis Heidner, one of the authors of the "IMAGE Handbook," sent
>us this note on our April net.digest column.
>
>"In the April 1996 net.digest column, "IMAGE Logging: When to Reset", you
>stated that "The consensus was that database capacity changes should NOT
>necessitate the refreshing of logging cycles."
>
>WRONG! Unless significant changes have been made to TurboIMAGE (or
>TurboIMAGE/XL)  in the last year or so... the primary key is not logged
>UNLESS the key itself  is changed.   TurboIMAGE records the dataset number,
>the dataset record number (not key value) and the before and after values
>that were changed.
>
>For detail datasets, it is possible to have multiple entries with the same
>primary key.  Thus knowing only the key value is insufficient for
>re-applying the transaction.  The original dataset record number must be
>available and valid.
>
>For manual datasets it is important to remember that you can design a
>database which has additional non-key data fields as part of a manual
>master dataset record.  A capacity change will force the re-sequencing of
>the data entries.   Thus changing the capacity on manual master dataset
>would be fatal for many applications, should you later attempt to recover
>based on your recommendations.
>
>The most important tip to remember is that those warning messages are being
>displayed for a reason. If you ignore them, you may later pay a much higher
>price (lost time), then if you had just stored the database and started a
>new cycle."
 
Really?  I had always believed that log records associated with master data
set modifications always included the key values of the associated master
entry modified (dbput, dbupdate, or dbdelete transactions). Thus, when the
log file was replayed by DBRECOV, the corresponding record would be
correctly found and modified irrespective of whether the data entries had
been relocated due to a capacity change.
 
For details, capacity changes do not alter data entry locations, and so
would have no undesireable impacts upon subsequent DBRECOV invokations.
 
If I understand what Dennis is saying - and if he is correct, then I - and
many others, I'm sure - need to rethink our database logging strategies.
 
But I still find it difficult to believe - mainly because I do remember
actually testing a DBRECOV with a log file interrupted by a manual master
capacity change quite a number of years ago, without any resulting problems
whatsoever.
 
Perhaps, time permitting, I will restest my long-ingrained beliefs in light
of these comments by a very well-respected authority on IMAGE.
-----------------------------------------------------------------------------
   Gilles Schipper                    Voice:      905/889-3000
   GSA Inc.                           Fax:        905/889-3001
   300 John Street, Box 87651         Internet:   [log in to unmask]
   Thornhill, ON  Canada  L3T 7R4     Compuserve: 71203,474
-----------------------------------------------------------------------------