COLUMN

Synopsis

HELP:   Description of all columns in the row
TYPE:   OBJECT
SYNTAX: COLUMN[(NAME='str',FORMAT.{},PROCESS[{}...],TYPE.{},MINLEN=num,MAXLEN/FIXLEN=num,PATH='str',ROOT='str',VALUE='str',CHANGE='str',VARFMT=PLENPTR/ALENPTR/PPTRLEN/APTRLEN/PFLGLENPTR/PPTRLENFLG/PCLNDLNCOLDAT/PFLGCLNDLNCOLDAT/AFLGCLNDLNCOLDAT,REGEXP(),INDEX(),POT='str',LOOKUP,NOCASE,LITERAL,UPDATE,NOTMTD=ZERO/MASK/RAND/IBAN)...]

Description

This object is used to describe how to extract a specific column from each row. Optional pre-processing steps (e.g. decryption) can be applied separately before a conversion to a neutral data type is done as last step for every column. The neutral format of the extracted data can be validated using a regular expression.

For archiving the read data, their indexing and pot design can be optionally provided here. Indexing is a must if you want to calculate signatures for the later search.

The column name is a logical qualifier which can later be used to address the column. For different supported structured formats, a path can be specified. This path is appended to the root path which may be specified in table and row objects. If no path is provided, the logical column name is used.

To simplify the specification of formats, processes and types, several default values can be specified. These settings will override the corresponding settings of the row object.

As part of the end of table handling you can define a logical table name over the keyword 'CHANGE' which activates monitoring of changes in this column, which will result in a EOT return code if a change is detected. In such a case the table name defined in this column specification is used in the EOT handling process. You can place a star character (*) in the change string. The first star in the string will be replaced by a string representation of the changed column value. For example:

   col(name='GENDER' change='TAB*')

   "GENDER","NAME" ,"AGE"
   "M"     ,"Hugo" ,"43"
   "M"     ,"Pope" ,"32"
   "F"     ,"Maria","42"
   "M"     ,"Mike" ,"17"
   "F"     ,"Magd" ,"39"

The CSV table can now be split in male and female, depending on the character in the column GENDER and the table names given after EOT are 'TABM' and TABF'. At write you can only request the name and the age and the EOT handling can be used to produce 2 tables one with all female and another with all male entries.

This column change detection support was mainly introduced for users using only one row specification for different tables in XML. The first row will result in a table change, except if it is identical to the set default value for this column, because each use of a new row definition will start with this default as previously stored column values. If no default value is specified, for string and binary columns an empty string ('') and for integer and float the number zero ('0') is used. With this mechanism, you can control the EOT handling in the start phase of a table. You can ensure that the first EOT gives the first column with a defined change, if the default value is different to the value expected for this column or you can ensure to get the name of the row specification after the first EOT if all defaults match the expected values of the first row in the table. Later on, a row definition change will result in EOT and if you come back to a previous row definition, the old values are still used for compare.

If the first data block does not contain a complete row, you still get the table name of the first defined row specification. This mechanism only works in the expected manner if the block size is larger than the space required for the longest row.

For writing to a FLAM archive, you can also define the indexing of the columns when reading, which can be used later to search and change the compressed and encrypted data without having to pack all segments of a member. In this case for columns of the string data type, you can use the NOCASE switch to force the conversion of all upper case Latin letters (U0041-U005A) to lower case letters (U0061-U007A) for the signature generation, which then also applies to the data comparison. This makes it possible to realize non-case sensitive comparisons, but this must be taken into account when writing the data to the archive.

For archiving, a lookup table can also be requested for the column, which ensures that the data is unique and is particularly useful if multiple searches have to be performed in the same matrix.

You can also mark a column as a literal. In this case, the data is not stored in the corresponding pot, but in the global literal matrix, which is particularly useful for keywords.

If you describe a record for an update, you must be able to define which columns are to receive a new value. These can also be indexed columns or columns that are marked as primary keys. This must therefore be indicated here via a separate update flag.

If access to a column has been restricted via the key rights, the method for handling these columns can be adapted here. If you select a method here that manipulates the data (MASK, RAND, IBAN), the matrix can no longer be written back. These methods can therefore only be used when reading.

A column specification supports many powerful features which can be accessed with the parameters below.

Arguments