PxPlus User Forum

Twitter Twitter Twitter

Author Topic: Key function addition  (Read 1906 times)

Peter.Higgins

  • Diamond Member
  • *****
  • Posts: 124
    • View Profile
Key function addition
« on: June 06, 2021, 07:20:37 PM »
Key function allows a key string to be generated when explicitly stated:
SELECT .... FROM <fileno> BEGIN KEY(<fileno>, KEY=S1$:S2$:S3$)

It would be quite useful for this to also work indirectly as in: 
K$=KEY(<fileno>, KEY=str$,sep=$3E$)
where string is s1Value$:s2Value$:s3Value$

Currently I am building a string for the whole command and executing it to get the key from object parameters.

Mike King

  • Diamond Member
  • *****
  • Posts: 3810
  • Mike King
    • View Profile
    • BBSysco Consulting
Re: Key function addition
« Reply #1 on: June 07, 2021, 09:07:47 AM »
Not certain what you are looking for and how it would be benefical.

Currently you can use the KEY(nn, KEY=x$:x1$:x2$) to generate the key, also you can use the KGN function to generate the key based on the record contents.

Also you can specify more key fields than needed.  For example if writing a generic access routine simply code it as KEY(nn,KEY=arg(K$,1,sep):arg(k$,2,sep):arg(K$,3,sep) ...
Mike King
President - BBSysco Consulting
eMail: mike.king@bbsysco.com

Peter.Higgins

  • Diamond Member
  • *****
  • Posts: 124
    • View Profile
Re: Key function addition
« Reply #2 on: June 07, 2021, 12:12:50 PM »

I am looking for generic Key padding that handles all keys for a file where only a key number and a
key string need to be passed, delimited if containing multiple fields.  A single string allows an easily
remembered generic interface. 

After you suggested the KEY function, I have found it to support a simple interface,
be very dependable and reduce revision and testing load. Definitely a huge improvement. 

Using ARG with KEY becomes more cumbersome than execute with numerous alternate keys
as testing a trailing :+null value generated an error.

KGEN would be perfect for a clean interface as I prefer passing records regardless of
key type and data layout to minimize future maintenance interface issues.  I can live
with the legacy edge case of the key not being in the data as that is becoming rare:)
Granted I don't remember having used KGEN in the last seven years but it has been on
my work around list for years due to prior edge cases with alternate keys
and with 2 forked versions.