Thus it was written in the epistle of Wirt Atmar,
>
> 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.

Seems like it would be considerably less efficient.  When I do the delete, I
would expect IMAGE to go to the current record, check its pointers to see if
any records were on the chain where as a DBFIND implies, conceptually at
least, a rehashing of the value.

> 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.

Would you consider as safe to loop through the master set twice, ignoring on
the first pass any primaries with secondaries in their chains and then
returning to remove, if necessary, any "encumbered" primaries?  That way,
secondary migration would be of no import.

Ted
--
Ted Ashton ([log in to unmask]), Info Sys, Southern Adventist University
          ==========================================================
A good notation has a subtlety and suggestiveness which at times make it
almost seem like a live teacher.
                        -- Russell, Bertrand (1872-1970)
          ==========================================================
         Deep thoughts to be found at http://www.southern.edu/~ashted