[Info-vax] Indexed file read question

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Wed Nov 18 12:24:04 EST 2020


On 2020-11-18 16:35:41 +0000, abrsvc said:

> On Wednesday, 18 November 2020 at 11:20:54 UTC-5, Stephen Hoffman wrote:
>> On 2020-11-18 15:23:13 +0000, abrsvc said:
>> 
>>> Situation: Indexed file with 2 keys, the first key no duplicates, 
>>> second key no duplicates. For clarity, the first key is a record  
>>> number and the second key is one of 4 values: A,B,L or blank.
>> With only four records possible, why is this even a file? Which  
>> implies there *are* duplicates on the secondary?
> 
> I have over simplified the situation just to provide a context for the 
> question.  This is just one of many questionable practices wihtin this 
> code system.
> More time is spent opening and closing files with singular records than 
> anything else.  I am not in a position to change this, I am just trying 
> to assist with understanding how the current system works.
> 
> Update:  There are duplicates for the second key.

I've long assumed the order of record retrieval is indeterminate when 
switching to a secondary key with duplicates; that's what is documented.

That secondary key would usually be created as a segmented key here, if 
the primary is to (also) be involved in the ordering of secondary 
record retrieval.


-- 
Pure Personal Opinion | HoffmanLabs LLC 




More information about the Info-vax mailing list