Ted writes:

> The code *I* have to write actually is much shorter for the "negative" than
>  for the "positive".  Unless I've misunderstood something (and the code is
>  as-yet untested, so that's likely :-), the positive test, with care taken
>  for migrating secondaries is something like this:
>
>    rewind dataset
>   +serial read on master
>    if not finished yet
>     *find on detail
>      if not found
>        delete master record
>        if that was a primary with secondaries
>          reread master record (mode 1)
>          loop to *
>        otherwise
>          loop to +
>      otherwise
>        loop to +
>
>  For the negative, with the same care for secondaries:
>
>    rewind dataset
>   +serial read on master
>    if not finished yet
>     *delete master record
>      if that was a successfully deleted primary with secondaries
>        loop to *
>      otherwise loop to +
>
>  Perhaps I haven't the right psychology, but that seems like a considerable
>  difference.

The reason that your first bit of code is longer than the second is that
you're basically duplicating the same test that IMAGE itself performs before
it performs the delete. While that may be psychologically safer, it could be
described as a bit more inefficient as well.

Personally, I wouldn't write either task using the methods described above.
In the interest of absolute safety above all else, I would first perform a
serial scan of the manual master and write every key value's entry off into a
flat file.

After that was completed, I would then loop back to the beginning of the flat
file and attempt a DBDELETE on each of the values in the file, one by one.
Doing this is the truly "safe" procedure. Masters are better addressed from
the outside world by their values than by the current addresses those values
occupy. By doing this, you're letting IMAGE do all of the work of managing
the secondaries -- and that is code that is truly safe and well-tested.

Wirt