The database engine built by Future Lab is called Bbuuzzband also has the internal technical name dbeng. The engine is based on typeless string data with variable field and record size. Any number of ifields may be present in the record and records may have a different number of fields.
The database engine uses special ASCII characters to delimit records and fields. Here are the delimiters used by the database engine:
The above list starts with a description of the database delimiter, the define (in dbeng.h) and the actual ASCII character code.
In theory the size of a record/field is only limited to the amount of memory that can be allocated (actually, there is a 9,999,999,999 record/field size limit due to the record header [see below]) except for the DOS platform were there is a 32000 byte record/field limit) but, to keep things simple, I have imposed a 64000 byte record/field limit.
Each database table represents one physical OS file. The database engine does not use container files. The physical structure of each data file is a series of records with each record delimited by the record delimiter. Each field within the record is delimited by the field delimiter. At the beginning of each record there is a 12 byte record header consisting of:
A|DnnnnnnnnnnFM
Where the first byte of the record header is either A for an active record or D for a record marked for deletion. The next 10 bytes (denoted above by nnnnnnnnnn) consists of the length of the record in question. Note that since all engine data is string based, the length is also stored in character form. The last byte of the record header (denoted above by FM) is the field mark.
Access to the data table by the engine is sequential. At the moment, there is no provision for indexes. When a record is re-written, the old record is marked for deletion and a new record is written. New records are always written to the end of the table. As the table builds the number of records marked for deletion, the pack function should be run against the specific table (autopack may also be used).
The database engine has no concept of a key field. The notion of a key field must be imposed by the developer. Since there is no key field concept, duplicate values are allowed in any field. Duplicate key detection and handling must be handled by the developer.
The database engine relies on the word parsing abilities in the library module parse.c. The database engine and API's also depend on the database header files. In the Linux/Unix/QNX platforms, the database modules can be compiled using the script cdbeng.
The database API is divided into low level and high level modules. The low level consists of the engine itself in the module dbeng.c. There are two versions of the high level API, one for single user applications (in the file dblocal.c) and one for client/server applications (in the file dbcs.c). The high level database API modules are based on database tids which uniquely identify the table instance.
The database engine also contains configuration options specified in the database configuration file.
This module is the high level client/server database API. The functions in this module build a command string and send this information to the database server. A reply code and any returned value from the database server is accepted upon return.
This module is the high level client/server database configuration API. This module consists of various get and set functions to deal with database configuration items.
This module is the low level database engine. All engine operations that deal with file I/O are contained within this module. The functions in this module are intended to be called only by other functions in the module or by functions in the single user database API module (in the file dblocal.c). Your database applications should always use the high level database API.
This module is used to manage low level database configuration details. The functions in this module are intended to be called only by other functions in the module or by functions in the database engine module (in the file dbeng.c) or by functions in the high level single user database configuration API (in the file dblocfg.c).
This module contains functions to translate Bbuuzzb engine codes to an English phrase. The module contains functions at both the dbeng low level and the db high level. This module must be linked into every application that uses the single user engine (dbeng.c and dblocal.c) or the client/server database API (dbcs.c).
This module is the high level single user API for the Bbuuzzb engine. Every application that uses the single user version of the database engine must link with this module.
This module is the high level single user API for the Bbuuzzb engine configuration details. Every application that uses the single user version of the database engine must link with this module.
This module contains the session table management facility. Technically, this module is not part of the database API as it is linked with the database server only.
This module contains the functions to implement the system catalog. This module must be linked with every application (single user or client/server) that uses the Bbuuzzb database.
This module contains the functions to manage server replication. Technically, this module is not part of the database API as it is linked with the database server only.
This high level module consists of functions which will get and put fixed-point numbers from/to a database table.
This low level module contains functions that will sort a database table.
This high level module is strictly not part of the database engine but is used to import ASCII data into Bbuuzzb tables based on a template.