[Info-vax] Indexed file read question

[abrsvc]

On Wednesday, 18 November 2020 at 19:14:57 UTC-5, Stephen Hoffman wrote:
> 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

That makes sense.   So as I thought I stated:  If a read is done using a primary key first then a read using a secondary key, the "starting point" is the position within the file based upon the first read such that read #2 will return the first record with the matching secondary key that appears AFTER the first record read rather than the first record in the file that matches the secondary key.