Storing records in the database with BINILOAD

The following table is intended to help the administrator decide whether to use BINILOAD or an application program for this purpose.

Keyword	Application program	BINILOAD
Generally used	to update the database.	to load a database.
Stores	every record of a record type individually in the database.	large numbers of records of a record type in the database in one or more runs.
Suitable for loading	a database containing many set occurrences with few member records.	a database with set occurrences which have large numbers of member records.
When inserting into sets	the correct set occurrence and the position within this set occurrence must be determined separately for each member record.	all member records which are to belong to a specific set occurrence are made available as a sequence of records of an input file and processed jointly.
Efficiency in loading the database	bears no relation to the number of records stored.	increases in proportion to the number of records to be stored.

Table 20: Comparison of application program and BINILOAD

BINILOAD is designed for loading a database and can efficiently load a large number of records of one record type.
Whether BINILOAD represents a saving in time compared to an application program, and how much time it saves, depends on the number of records to be loaded, and the structure of the database.

Since BINILOAD does not use before-images, DBDIR and at least the realms required on loading should be saved before a run, especially if a check run is not going to be carried out.

BINILOAD enables records of the same record type to be stored in an empty or partially empty database. It is important to make all the records to be loaded available in an input file for BINILOAD. All records loaded during a run are stored in the same realm by BINILOAD. It does not matter if records of the same record type are already contained in the database. In each run, BINILOAD only processes records of a single record type.

BINILOAD can

• load data from CSV files;

• presort the records of the input file;

• store records with items of fixed length and variable length;

• generate empty set occurrences for owner records which it has stored;

• when storing member records, insert all records of the input file into a set occurrence nominated by the DB administrator, or select, using the key value of the owner record concerned, the individual set occurrences into which the records are to be inserted.

BINILOAD determines the sequence of member records in compliance with the sort criteria specified in each case and sets up the set occurrence tables so that relatively few accesses to the pages of the database are necessary.

It is also possible however to stipulate the member record sequence desired by specifying a character string in the records of the input file (only for sets where ORDER is not SORTED or SORTED INDEXED, e.g. ORDER IS LAST).

BINILOAD accesses the database directly and not via the DBH. DB records (including set connection data) and tables (pointer arrays, lists, SEARCH key tables etc.) are generated by BINILOAD in work files or in main memory. BINILOAD then assembles the complete pages before transferring them to the database.