> In all of the Image classes I have taught (62),  I have
> maintained that if
> you want the chain in chronically sorted sequence then it is
> best to specify
> a time stamp as a sort item (ccyymmddhhmm). This costs some
> extra disc space
> but doesn't rely on any assumed or possibly misunderstood
sequencing.

I definitely agree--but I'd also definitely use something more
fine-grained than minutes for the sort item. Seconds as a minimum,
centi- or milli-seconds would be even better.

> An added benefit is  that with btree retrieval one can add a
> path on the
> time stamp and do a monthly report by using DBFIND with an argument
of
> [log in to unmask]

Ouch! If you're going to make such a sort-differentiator a search
item, break it into pieces; with a search item like this
(CCYYMMDDHHMM), you'll have thousands (millions?) of very
short--frequently length one--chains. IOW, the number of records in
the master set will be within an order of magnitude--maybe within a
factor of 3--of the number of records in the detail set. I'd at least
break the search/sort item into two parts, like CCYYMMDD and HHMMSSCC
(that last 'CC' is centiseconds), and key only the CCYYMMDD part.
Which should be low cost, since it's virtually guaranteed that you
already have other CCYYMMDD fields in your database that are search
items, so the auto master already exists. Of course, this is where we
start to run into the exists-for-no-good-reason limit of 16 paths in a
master set....

Steve


Steve Dirickson   WestWin Consulting
[log in to unmask]   (360) 598-6111