<<There clearly is not the 'order of magnitude' of more space needed to use a b-tree to index a detail for sorted-sequention access. Overlooked is the fact that with IMAGE, the b-tree simply provides the next master key. From that master key is obtained the pointers to the corresponding details. These IMAGE pointer chains require 6 half-words for the master and another 4 half-words for each detail entry.>> Apples and oranges, I think. This is only true when the item that is to receive the B-Tree index is not already a search item in the detail set. I submit that the majority of databases where we will be using the new sorted-sequential index capabilities are configured such that the bulk of the newly-indexed items are already search items. Obviously there will be cases where people will create new automatic masters purely to get the SS-index capability, but I think it will be a minority usage. Certainly for our databases here, the existing 40-or-so automatic masters will probably not increase by more than a half-dozen at the most. For detail sets with existing search items that will now have SS-index capability, I reiterate that the alternative of an Omindex/Superdex index directly on the detail set would require the "orders of magnitude" more disk space than the B-Tree index on the automatic master set. As mentioned, someone who needs full-text indexing or something similar should look at using one of the TPI products. In fact, if they "really, really" need the capability, they are probably already using one of them. Steve