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