file statement

The file statement is a compiler directive that allows the use of attribute definition items in the file’s dictionary while compiling a program.

Syntax

file file1{,file2...}

Parameter(s)

file1 {, file2...} Specifies the files from which attribute definition items are extracted for use in program compiling. Multiple files can be specified (for example, file2, file3, and so on) in the same statement, separated by commas. File paths are currently not allowed in the file statement.

Description

The file statement is typically used to allow the use of attribute definition items to identify the attribute count of the field and automatically apply dictionary correlative codes to the field value in the item.

When the FlashBASIC or BASIC compiler encounters a file statement, it opens the dictionary of the file specified by file1, creates the executable code to open the data portion of the file during execution, scans the FlashBASIC or BASIC code for references to the given file, and dimensions an array with the same name as the file specified.

The size of the dimensioned array is determined by the compiler. It scans the program looking for references to attribute names as dimensioned array subscripts (for example, file1(credit.limit)). After it has found all references to the given file, it takes the highest attribute count reference derived, adds 1 to it, and uses the resulting value as the size of the dimensioned array.

After an item is read from the file, attributes within the item can be referenced by using the attribute name from the associated dictionary as the array subscript. Correlative processing codes found in the file dictionary are executed, but output-conversions are not. Values within an attribute can be specified by appending a command and a value count to the attribute name or number.

read and write statements cannot specify the file variable when the array name file1 is used as the variable.

The file pointer is assigned to the file variable in the form fv.file1 and references the data section of the file opened.

Note: D3 does not currently support the use of path names in the file statement. This prevents opening an alternate data section on a file. The way around this limitation is to build a Q-pointer to the appropriate data section and use the Q-pointer in the file statement.

When referencing numeric attribute numbers (for example, entity(1)), if there are attribute-defining items (ADI) in the dictionary with numeric item-IDs (for example, 1), the attribute-defining item is used and not the direct (numeric) reference. The sequence of precedence is attribute-defining item first, followed by numeric reference; therefore, care must be used when mixing numeric and alphanumeric references.

Changes to attribute definition items made after the program has been compiled are not reflected in the object code. Because binding takes place during the compile phase, the program must be recompiled whenever an attribute count or correlative is changed.

Because the file statement creates an array for each file opened, file names must follow array naming conventions. Therefore, all numeric file names are not supported.

Example(s)

The file entity is bound by the file statement. When item "100" is successfully read, the name field is checked. If the name field is null, "no name" is output to the terminal.

file entity
ID = "100"
read entity from ID then
if entity(name) = "" then crt "no name!"
end

This determines if the file variable fv.entity has been assigned by AQL to the Update processor. If it has not been assigned, the file statement is executed. This technique is particularly useful when calling subroutines from AQL, and prevents having to reopen a file each time the routine is called. Using this logic, the file statement is executed once.

fv.entity = access(1)
if not(assigned(fv.entity)) then file entity