High-level Description of the InterBase 6.0 Source Code

By Ann Harrison

Now the InterBase sources are released, as developers you will find yourself facing a significant amount of code, varying widely in sophistication and relevance.


The engine directory is "jrd" - "Jim's Relational Database" - not one to hide his light under a barrel is our Jim. The external entry points are in isc.c.

They generally call a matching set of internal routines in JRD.C. JRD calls off to CMP.C to compile requires, MET.C to find metadata, and EXE.C to execute a compiled request. When EXE.C wants data, it calls RSE.C (record source expression, I think).

It uses BTR.C (b-tree) for index lookups, VIO (virtual I/O) to get records by record id, SORT.C for sorting (surprise!). VIO gets its records from CCH.C, the cache handler. CCH is the lowest level that has any concept of page types or structured data. It calls PIO.C to do the actual reading from disk.

MET.C is a preprocessed file. The actual file is "MET.E". Other preprocessed modules are DPM (data page manager - it works with VIO, getting records and cleaning up stuff), DFW (deferred work. It creates indexes and actually makes metadata changes when a transaction commits.)

EVL.C evaluates expressions. CMP.C performs comparisons. FLU.C is the function look up module. GDS.C has service routines, visible outside the server.

CODES.H is an interesting problem. It's created by CODES.E (precompiled to CODES.C) from the message database. You need codes.h before you can build the engine and the engine before you can run CODES.C.

Another module worth looking at is ALL.C, the block allocation (and deallocation routine). The old utilities also have an ALL.C module.

Coding conventions

Externally visible routines are XXX_<name> where XXX is the three (or four) letter module name. Routines in a module start with the external routines in alphabetical order, followed by the internal routines in alphabetical order.


The Guardian is in the ISCGUARD directory. It's a windows thing.

Server-side Client Interface

See below.

Client-side Client Interface

Both these bits are in the directory REMOTE. It's a cute architecture, which requires more explanation that I can provide here. As far as I know, it can't be explained without a whiteboard.


See below.

InterClient and InterServer

See below.


They'll show up, but they're a mystery to me at the moment.


ISQL and WISQL ISQL directory. qli

QLI Directory

Query Language Interpreter. It's a command line interactive query language with "procedures" which are stored sections of QLI code that are invoked like macros (without arguments, worse luck).

Starts at DTR.C (Datatrieve, its paternal ancestor). Commands and statements (they're different) go through LEX.C (which breaks them into lexemes) PAR.C (which parses them), COMPILE.C (which compiles them). GENER.C generates BLR.

QLI, like all the old utilities, uses the BLR interface rather than DSQL. PICSTR interprets data formatting instructions - lots of them. Jim objects strongly to pronouncing it "pick stir".


BURP directory. (Back Up Restore Program). The main modules are backup.e and restore.e. The entrypoint is in BURP.C.


ALICE directory. (All Else).


Source code management system.


Test control system for regression testing. TCS will be provided with a small set of tests, orgainized in series and metaseries.


Forms editor for a very creaky VT100 style forms package.


The aforementioned forms package.


An unsuccessful graphical query language. These three gems seem to have disappeared. If I can find the code and if I can convince Borland to release it, I'll expose them to the light of day.


DDL utility. Interpreted commands in the old data definition language (declare relation, declare field - square brackets where you want to put parentheses). Generates BLR for views and triggers, GDML (non-SQL relational language) for metadata updates.


Preprocessor for static SQL and GDML. Internally much like QLI, except that it understands COBOL. Probably the best BLR generator of the bunch.


dsql The dynamic sql processing. Originally, DSQL was compiled into BLR on the client side, requiring that the client have a copy of the relevant metadata. Now, DSQL strings are passed and interpreted on the server side and parsed into BLR there. extlib The predefined "user" defined functions.


In the INTL directory. This will make a great deal more sense when you've read Dave Schnepper's paper.

Lock Manager

In the lock directory. Used for classic architecture versions to coordinate page access (and such things). Based on the VMS distributed lock manager.


Subsystem for creating, checking, and changing message text.


Server manager appears to be here, and gsec.


Write ahead log. Dead, to the best of my knowledge.