[Info-vax] Help with DECBasic: reading a record in an INDEX SEQ file using a compound key

Hein RMS van den Heuvel heinvandenheuvel at gmail.com
Wed Jan 6 13:09:21 EST 2010


On Jan 6, 8:01 am, thick_guy_9 <jose.santos.mouri... at gmail.com> wrote:
> All
> I need some help with DECBasic. All the examples in the BASIC USER
> GUIDE use a simple key.

The key segments only play a role in the OPEN, and even there they are
optional.
You can just NOT name any keys and have Basic figure it out from the
file itself.

key segments play NO role on the record access statements like GET,
FIND, PUT.
Just just provide a SINGLE piece of string to correspond with the
concatenated key fields.
You can fill and provide, the corresponding fields from the MAP are
used, but that's not needed, only practical to get the segment sizes
right.


> FIND #1, KEY #0 EQ "sMyPAN,sDOB", REGARDLESS

> The above Get command gives me a "RECORD NOT FOUND" error.

As Frank also replied, you got it all wrong there.
Basic told RMS to look for a record with the key being a string
starting with 'sMy'.
Surely you intended to provide the contents of variables with those
name.
Do as Fran writes, or make the key explicit

for example

PAN = sMyPAN
DOB = sDOB
mykey$ = PAN + DOB
GET #1,  KEY #0 EQ mykey$, REGARDLESS

Notice how  I replaces FIND + GET with a direct call to GET.
That saves a trip into RMS.
There are  times and places where FIND should be used, but they are
relatively rare.

> Did I get the syntax correctly?

Yes, otherwise the compiler would complain.

 :-)

No, not with respect what you intended to achieve.

Also... some free advice...

I hope that the target is a SMALL file or at least one with infrequent
inserts.
and alternate key based on FIRST name is likely to have lots of
duplicates and be of little use. At least extent that with a leading
part of the lastname as segment, to get it pre-sorted by last names,
and reduce duplicate counts.

Ditto for last name. Add a first name segment or a DOB or something,
anything!

Finally more often that not a ( PAN ) number is a lousy choice for
primary key.
Last name is often much more efficient.

Hein
HvdH Performance Consulting.



More information about the Info-vax mailing list