Dictionary A and S-type records

Dictionary A and S-Type Records  -  Pick Style Data Definitions

Top  Previous  Next


A and S-type dictionary items are an alternative to the preferred D and I-type items that describe data stored in database files. QM provides a limited subset of the full A and S-type functionality found in other multivalue database environments. There is no difference between A and S-type records within QM.


An A or S-type record has up to 11 fields:


1:Type (A or S) plus optional description
2:Location of this field (field number)
3:{ Display name to be used by LIST or SORT when displaying this field. The text can commence with 'R' (including the quotes) to right justify the heading, 'X' to suppress the normal dot filler characters, or 'RX' to apply both modifications. }
4:{ Association }
7:{ Conversion code for entry and display of this field }
8:Correlative code.
9:Display justification
10:Display width
11:Available for user use. Not referenced by QM.
12+Reserved for internal use



Field 2 of an A or S-type record holds the field number of the data record to which this dictionary entry relates. This must be a positive integer value. A value of zero may be used to refer to the record id. For compatibility with other multivalue database products a value of 9998 or 9999 will be recognised by the query processor as references to the sequentially incremented item number within the query and the length of the record respectively. Both of these special cases are better implemented using I-type records. Where field 8 contains an A or F correlative, the value in field 2 is not used.


Field 4 defines the relationship between associated multivalued fields. Within an association, one field is considered to be the controlling item and the remainder are considered as dependant. The controlling field has C;p;q;r in field 4 where p, q, r (etc) are the field numbers of the associated items. The dependant fields all have D;n in field 4 where n is the field number of the controlling field. Internally, QM converts Pick style association definitions into an association name __n. Alternatively, this dictionary field may contain an association name as used in C/D/E/I-type records. For compatibility with some other multivalue database products, the ASSOC.UNASSOC.MV mode of the OPTION command can be used to make the query processor treat all multivalue fields that are not in defined associations as being associated together.


Field 7 contains an optional conversion code to be applied immediately before the data is displayed in a query processor report. QM has only partial support for use of A or F-correlative expressions in this field.


Field 8 contains an optional expression to be evaluated to calculate the value of the item. This may be an A or F correlative, an IF expression as an implied A-correlative, or a conversion code to be applied to the field identified in field 2 of the dictionary record. Conversion codes appearing in field 8 are applied immediately to the data extracted from the record and hence affect sorting and selection.


Field 9 contains the justification code L, R, T or U that determines the alignment of data in a query processor report. For compatibility with Pick style systems, the justification letter may be followed by an "X" qualifier. When used as a display item in a query processor report, the display width of all items with this qualifier is expanded to use any spare space across the line, forcing the inter-column spacing to be one character.


Field 10 contains the field width to be used in a query processor report.


Important note: In Pick systems, correlatives are processed in an interpretive manner. QM compiles A and S-type dictionary items in a similar way to I-types. This results in better performance but, if one dictionary item uses the value of another, it will be necessary to compile both if changes are made. The COMPILE.DICT command with no record ids will compile all A, C, I and S-type items in the specified dictionary.


QM does not support the LPV (load previous value) data item found on Pick systems as it is dependent on the exact sequence in which the query processor evaluates expressions. The query optimiser of QM could cause this to behave in an unexpected manner. It is always possible to restructure dictionary items that used LPV to work without it.