Variable declarations in detail

<< Click to Display Table of Contents >>

Navigation:  Report Generator > Report variables >

Variable declarations in detail

Previous pageReturn to chapter overviewNext page

Here follows a detailed description of the form and content of the database file NVARDEC.DBF, the New VARiable DEClarations DataBase File.

 

Here you will find references between the fields in the TARGET databases that the Report Generator gathers information from and the report variables used in the forms.

 

The database structure of NVARDEC.DBF looks as follows.

FieldnameType        Length        Decimals

 

DATNAMEC        8        0
VARNAMEC        20        0
FLDNAMEC        10        0
BUNDC        1        0
PAR1C        3        0
PAR2C        3        0
BESCHREIBC        80        0

 

NVARDEC.DBF contains over 2000 variable declarations that describe all report variables that can be used in the forms for the Report Generator. A variable declaration consists of a record in NVARDEC.DBF. The fields in that database file have the following functions:

 

a)The DATNAME field normally declares in which database file the fieldname (FLDNAME) can be found. In addition, there are some special cases:

 

1.        If the field is empty,"        ", the row contains a system variable declaration.

 

2.        If the field begins with "KATALO", the entered field name corresponds to one of the database files that the Catalogue uses, and more specifically the one that has the suffix that follows after "KATALO" (like the *KT for “KATALOKT”).

 

3.        If the field begins with "PROJECT", the entered fieldname is found in the TARGET database file which is using the suffix that follows "PROJECT" (like *E.DBF for PROJECTE). The exception is PROJECTS which refers to the project parameter database PROJECTS.DBF.

 

 

c)The VARNAME field declares the report variable name used in the forms.

 

The report variable name is only allowed to be associated with one single database fieldname. If there occur several definitions with different fieldnames, only the first one will be valid.

 

 

d)The FLDNAME field contains any of the following variations.

 

1.        The fieldname of a field in a database file (xxxxxxx.DBF). During the report generating process, the content of the entered field is transferred to the associated variable in the forms.

 

2.        The name of a system variable. The system variables are either global (user defined) or of computation type.

 

 

e)The BUND field tells you whether the text transferred during printing of reports should be adjusted to the left or to the right. This is however only valid for text forms (FMT). In DXF forms, the text justification is defined directly by the variables in the form.

 

Alternative adjustments are:

 

L – align left
R – align right

 

 

f)The PAR1 field indicates the content of the PAR2 field, and it separates G database keys from each other when there are several keys in the same record of the TARGET database.

 

PAR1, character position 1:
E – Reduction in PAR2

 

PAR1, character position 2:

 

 Empty:        Variable declaration for G database key QUELLDWG

V:        Variable declaration for G database key QUELLDWG _V
N:        Variable declaration for G database key QUELLDWG _N
1:        Variable declaration for G database key QUELLDWG _1
2:        Variable declaration for G database key QUELLDWG _2
 
In plain text the G database keys mentioned above corresponds to:
 
QUELLDWG:        Devices directly associated with the symbol, as for example in device lists, and the terminals that are the foundation of terminal lists.
 
QUELLDWG_V:        Devices connected on the “from side” of wire lists, cable lists or cable core lists as well as devices connected on the internal side of terminals in terminal lists.
 
QUELLDWG_N:        Devices connected on the “to side” of wire lists, cable lists or cable core lists as well as devices connected on the external side of terminals in terminal lists.
 
QUELLDWG_1:        Cable symbols for cable cores in cable core lists as well as cable symbols for cable cores on the internal side of terminal lists.
 
QUELLDWG_2:        Cable symbols for cable cores on the external side of terminal lists.

 
 

g)        The context of the PAR2 field is indicated by PAR1 according to the following:

 

 PAR1, character position 1:

E ‑        If PAR1 position 1 is E, then a code for reduction (exclusion of certain information) is found in PAR2. The codes are binary weighted and have the following meaning, bit by bit:

 

       1 -        Redundancy reduction should be performed relative to the first row (record, line) in the current report sheet. Redundancy reduction can only be made on plant and location. If the first bit is 0, the reduction is made “hard”, regardless of the content of the first row.

 

       2 ‑        Reduce plant from complete item designation (always or when redundant, depending on whether the first bit is 0 or 1).

 

       4 ‑        Reduce location from complete item designation (“hard” or “soft” depending on whether the first bit is 0 or 1).

 

       8 ‑        Reduce plant from complete cross-references.

 

       16 ‑        Reduce location from complete cross-references.

 

       32 ‑        Reduce terminal number from or pin/socket number from complete item designations for terminals or connectors. This code does not affect item designations for conventional devices, cables, and PLC’s.

 

       64 ‑        Reduce pin/socket number from complete item designations for connectors. This code does not affect item designations for conventional devices, cables, and PLC’s.

 

       Some examples with item designations:

 

       E 7 ‑        “Soft” redundancy reduction on plant and location (7=1+2+4).

 

       E 35 ‑        “Soft” redundancy reduction on plant, and reduction of terminal and pin/socket numbers (35=1+2+32).

 

h)The BESCHREIB-field contains a description of the specific report variable in plain text.