Jeff wrote:

After I wrote:
>>
>> and John wrote:
>
>> >Furthermore (and I'm really going to display my ignorance here) isn't
>> >the b-tree pointing to the key and not the record number, thereby
>> >forcing the read down the synonym chain anyway?
>>
>> And this is true... Once the value is found, the master key is taken
>> from b-tree and used to find the record in the Master dataset.
>
>OK, I guess it was me displaying my ignorance.  I had presumed that the
>b-tree held the record number.  If it simply has the key value, then
>most of my argument was moot.

Well, this true for Omnidex and Superdex for *detail* datasets.  In this case, the relative record number is the pointer in the b-tree.  Since IMAGE b-trees are only available on master datasets, it is irrelevant.  However, if you have one of the third-party products, you can take advantage of the index, especially if you qualified value has a short "chain".  In this case, often the access can be done in one or two physical I/Os, and then the single I/Os to the detail records.  This is very similar to a standard IMAGE detail chain, which requires a hashed/calculated to the master value first (during the dbfind), followed by the single I/Os to the detail records.

So, I would say Jeff was more confused then ignorant :)

LB