Computers: Universe: Overriding DictionariesComputers: Universe: Overriding DictionariesYou may have noticed during the last section (see Listing Records) that you have not had to specify any display specifications for the columns in your enquiries so far. For instance, when you listed the TYPE column, you did not need to specify that you wanted a four character wide field justified to the left and with a heading of 'TYPE': all this information was derived from the dictionary of the COPY.OF.VOC file.
This is, of course, one of the strengths of UniVerse. The way in which a field is displayed depends above all on its contents: and of course its contents do not vary from enquiry to enquiry. It is therefore more efficient to define these details once in the dictionary of the file, and allow enquiries using the dictionary in question to 'inherit' the display details. This has the further advantage that if at some point in the future the contents and thus the display requirements of the field change, simply by changing the corresponding dictionary record all the enquiries using the record are updated.
Sometimes, though, enquiries will vary in the way in which they present fields. Very commonly, one enquiry which lists only keys and descriptions will wish to allow a wider column width to the description than another which shows many columns from the same file, and cannot afford the column space.
This problem, and one solution, have already been discussed (see Dictionaries). The most common solution is to define a 'synonym' dictionary record, evaluating the same data but giving it different display characteristics: such as a different column width.
There is another technique, though, which can prove useful where you are confident that the change you wish to make to the display characteristics of a field is unique to the enquiry you are working on. For instance, if you are running a 'once off', 'ad hoc' enquiry, you may not wish to go to the trouble of creating a new dictionary record simply in order to give one column greater width. More importantly, you may wish to avoid cluttering up the dictionary file with records never likely to be used again.
You can specify parameters which override specific dictionary parameters within your retrieve statement. This is perhaps easiest to illustrate by example. You may have noticed that in the sample enquiries run in the previous section, the DESC (description) frequently wrapped onto two or more lines within a fairly narrow column. You could avoid this by overriding the dictionary display width for the column like this:
>LIST COPY.OF.VOC DESC FMT "65T"
LIST COPY.OF.VOC DESC FMT "65T" 13:04:39 08-19-99 PAGE 1
VOC......... DESC.............................................................
F9 Data descriptor for Field 9 of any file
PRINT.ADMIN Paragraph
TEST.PARAGRA PA
PH
COMO Verb - Control copying of command output to files
NOHEAD Keyword - Do not print a banner page
LT Keyword - "Less Than" operator
BREAK.VERB Verb - Enable or disable INTR, STOP, SUSP, and BRK keys.
SUBO Verb - Subtract OCTAL numbers
ALL.MATCH Keyword - Specify that ALL strings should match for
SEARCH/ESEARCH statement
INQUIRING Keyword - Prompt for record name
LIST.ME Sentence - Return status of all users with your login name
IN Keyword - The word "IN"; ignored by RetrieVe
MAP.VERB Verb - Display a MAP of the contents of the system CATALOG
CONSYS.REPOR F
TS
MAKE.DEMO.FI Verb - Create demo files (8.3.3)
LES
STATS Keyword - Synonym for STATISTICS
Press any key to continue...
The FMT keyword following the DESC fieldname controls the format in which that field is displayed. It overrides the fifth line of the DESC dictionary record, which shows a format of 30T.
You can override most of the dictionary fields in this way:
CONV overrides the third dictionary record field: the conversion.
COL.HDG overrides the fourth dictionary record field: the column heading.
FMT, as we have seen, overrides the fifth dictionary record field: the format.
SINGLE.VALUE and MULTI.VALUE overwride the S or M in the sixth field of the dictionary record.
You can even list columns not connected to any dictionary record using the EVAL keyword. You can use the expression EVAL "formula" almost anywhere you can use a field name in a RetrieVe command. The formula works in precisely the same way as the formula found on the second line of an I-descriptor (see Imaginary Fields), and effectively means you can avoid creating an I-descriptor if you are confident that you will not be using your formula anywhere except in the current enquiry. EVAL is particularly good for 'ad-hoc' enquiries.
To take an example, imagine that you wished to include a column showing the length of the keys for all the COPY.OF.VOC records. You could create an I-descriptor to do this easily enough, but you've come to the conclusion that this information will never be needed again, so its best not to clog up the dictionary with the extra record. (Incidentally - I think you'd be right about this. It's difficult to think of a plausible reason why anyone should want such a bizarre statistic: but cut me some slack, it's not always easy writing training courses).
Using EVAL, your enquiry would run:
>LIST COPY.OF.VOC EVAL "LEN(@ID)"
LIST COPY.OF.VOC EVAL "LEN(@ID)" 13:22:58 08-19-99 PAGE 1 VOC......... LEN(@ID).. F9 2 PRINT.ADMIN 11 TEST.PARAGRA 14 PH COMO 4 NOHEAD 6 LT 2 BREAK.VERB 10 SUBO 4 ALL.MATCH 9 INQUIRING 9 LIST.ME 7 IN 2 MAP.VERB 8 CONSYS.REPOR 14 TS MAKE.DEMO.FI 15 LES STATS 5 PTIME 5 Press any key to continue...
Ok, so it works, but its pretty untidy. The numbers are left justified, and the column title simply a restatement of the formula. This is because without a dictionary record, you RetieVe doesn't know how to format the information. But you can use any of the keywords listed earlier in this section, like FMT, to solve this problem:
>LIST COPY.OF.VOC EVAL "LEN(@ID)" COL.HDG 'Key length' FMT '10R'
LIST COPY.OF.VOC EVAL "LEN(@ID)" COL.HDG "Key length" FMT "10R" 13:27:07 08-19- 99 PAGE 1 VOC......... Key length F9 2 PRINT.ADMIN 11 TEST.PARAGRA 14 PH COMO 4 NOHEAD 6 LT 2 BREAK.VERB 10 SUBO 4 ALL.MATCH 9 INQUIRING 9 LIST.ME 7 IN 2 MAP.VERB 8 CONSYS.REPOR 14 TS MAKE.DEMO.FI 15 LES STATS 5 Press any key to continue...
Isn't that better?
What if you now wanted to sort the enquiry by the length of the key? (This example is getting weirder and weirder, but stick with it.) If you were sorting by a fieldname, you'd have to specify the fieldname twice: once in the list of fields, and again in a BY clause. Does this mean you have to type the EVAL... with all its accompanying nonsense twice? Well, you could, but there is a better way. You can use the keyword AS to give a 'name' to your EVAL column, and then use the name in the BY clause. It's done like this:
>LIST COPY.OF.VOC EVAL "LEN(@ID)" COL.HDG 'Key length' FMT '10R' AS LEN.KEY BY LEN.KEY
LIST COPY.OF.VOC EVAL "LEN(@ID)" COL.HDG "Key length" FMT "10R" AS LEN.KEY BY LE N.KEY 13:42:12 08-19-99 PAGE 1 VOC......... Key length | 1 < 1 + 1 = 1 - 1 A 1 % 1 P 1 ) 1 ; 1 ~ 1 ? 1 & 1 * 1 Q 1 / 1 ( 1 > 1 , 1 Press any key to continue...
In fact, you can even use AS to provide a 'synonym' to an ordinary field too. Let's say someone took your formula and created a dictionary record called THE.LENGTH.OF.THE.KEY. Even to me (and I have always preferred long, descriptive and unabbreviated names for computer entities) this seems over the top. To avoid having to type it more than once, you could say:
>LIST COPY.OF.VOC THE.LENGTH.OF.THE.KEY AS LEN.KEY BY LEN.KEY