[Info-vax] Indexed file read question

[Stephen Hoffman]

On 2020-11-18 23:13:04 +0000, abrsvc said:

> Taking your statement as listed below and using your tmp.idx file as an 
> example.  Wouldn't the returned record for the keyed read using the 
> secondary key return the aap A record since it is the first in the file 
> with the secondary key of A rather than the first A record after the 
> initial read with key 0?

Hein is assuming a key search on the secondary key to start the 
sequential access on the secondary key, and that'd give you whatever is 
the first A record if that's what was requested, as was mentioned.

>From your key-switch comments, I'm assuming that's not quite what this 
code is doing. Rather, I'm assuming this code is doing a keyed search 
on the primary, then switching to and doing sequential $get operations 
on the secondary—sequential $get, not a keyed-access $get or 
keyed-access $find—from whatever record you're already positioned at on 
the secondary.

If you're doing a sequential $get from what is effectively an 
indeterminate position within any group of duplicates present on the 
secondary key—again, a starting position within the duplicates present 
on the secondary key, as determined by what is an unrelated primary key 
$get or $find access—what record might you sequentially $get on the 
secondary key is indeterminate.

The ordering for the primary key is indeterminate when accessing 
records sequentially on the secondary key.

It is entirely possible that your sequential $get on the secondary key 
could start from an "A" record and the sequential $get on the secondary 
key could then return a "B" record, if you happened to start on the 
last A among the duplicates.

If a developer wanted to reliably and efficiently acquire a selection 
of records associated with the primary key, you'll need to extend the 
primary key to include that field or (more commonly, as the data might 
not be adjacent) define the secondary key as segmented key that 
overlaps with the primary and the field containing that "A", "B", "L" 
or " " value.

RMS files that get churned with added and deleted records can to build 
up trash within the indexed structures. Performance issues are common 
here as the detritus accumulates.

There are various ways for inefficiencies and coding bugs to be added 
here, too.


-- 
Pure Personal Opinion | HoffmanLabs LLC