<<Many people keep data in detail datasets with automatic masters, rather
than in manual masters so that it can be accessed by other keys.  If you
want to add a B-tree to this dataset on, say, a name field, then this
field must be given its own automatic master in order to access it using
a B-tree.  This adds one extra level of updating and searching as
compared to a B-tree constructed directly on the detail data set.

From another point of view, if you want more than one B-tree on a
particular dataset, it must be a detail and there must be a master
(automatic or manual) for each index.>>


You got it.

However, the "one extra level" you mention will more often have the
effect of *reducing* index update activity-sometimes dramatically. If the
sorted-sequential index were directly on the items in the detail data
set, the index would have to be changed every time the record moves
(which, if CIUPDATE is not in use, means every time a search item-any
search item in the set, whether or not it is the one with the SS
index-changes value) or when an SS-indexed search item changes value when
CIUPDATE is in use. With the SS index on the master set, the index only
has to be updated for a given value if the update is the addition of a
not-currently-existing value for the search item or is the deletion of
the last occurrence of that value for the search item.

In addition, putting a sorted-sequential index directly on the detail
sets would require significantly more disk space-orders of magnitude
more. With the SS index on the master set, you get a free "compression
factor" equal to the number of sets keyed on the automatic master set's
key item, times the number of occurrences of that value in all sets with
an index. IOW, instead of having, for example, 5 index files, each of
which must provide the location of every occurrence of the specified
value in each of its associated detail sets, say a total of 1000
occurrences, you have one index file, that specifies the location of the
value in one set. Simplifying the numbers, that's an effective
compression of 1000:1 for a 4-byte item, or 100:1 for a 40-byte item.

If you want full-text searching of lots of data, or need search options
beyond the fairly basic capability of the TurboIMAGE B-Tree indices,
Omnidex or the equivalent is clearly the way to go. But the new
capability will add a lot of options that we've been waiting a long time
to see, and will do it with amazing efficiency.

Steve