TABLE

Synopsis

HELP:   Format data blocks in a list of rows with columns (tags, attributes, data, ...)
TYPE:   OBJECT
SYNTAX: TABLE(METHOD=AUTO/BLOCK/RECORD,FORMAT=FIX/LFD/DLM/VAR/CSV/TVD/XML,DEFAULTS(),ROW[()...],IGNRST,ENDOFT,BUFSIZ=num,INICNT=num,PATH/ROOT='str')

Description

The object "format table" is used to describe the structure of rows in a table. There can be one or more row format specifications which tell FLAM how to break up rows/records into cells of the table. Each column is parsed independently with optional pre-processing steps (e.g. decryption).

At least one row must be specified. If there are multiple row specifications and a format error occurs while trying to read the row according to the first row specification, reading with the next row specification is attempted until the row matches one row specification or until all available row specifications failed, which results in an error.

When specifying multiple row formats, you have to ensure that the row formats are distinct from each other to ensure that one row format cannot be mistaken for another.

To simplify the specification of rows, you can set a format specifier and several default values. You still have to describe each column, but depending on the default settings, only the missing or differing parameters must be specified for each column.

You can specify whether a block- or record-oriented method is used for parsing. By default, the method is assigned automatically depending on the data. The block-oriented procedure ignores the record length and interprets the data as one chunk of data. The record-oriented method ensures that each defined row must fit within a record. For XML files, only the block-oriented approach is reasonable.

At the end of the data, a remaining rest results in a format error. You can activate the corresponding switch to ignore this.

If you want to use the filename substitution rule [table] to split multiple tables contained in one input file into multiple files by using each table's name as part of the output filename when writing, the end of table handling must be activated. This switch will cause a FLMRTC_EOT error if the end of a table is reached. The error handling procedures in FLAM's utility programs will ensure that each table is written to the right output file. On the API level, the application must handle this error. A function of the respective API can be used to get the name of the current table after opening the input file and after an EOT error. To be backwards compatible with old applications, the EOT error handling has to be activated explicitly.

For XML or other structured data formats, the optional starting path (e.g. root tag in XML) can be defined for the entire document. This path will be prefixed to the paths defined on higher levels. This simplifies the definition of the complete path to an element. A mix of XML with other data formats in one file makes no sense and is not supported. For more information about XML paths see FORMAT.XML().

Arguments