Perhaps I’m being unfair to the DCONVERT program, because it was my fault in using the ‘y’ in the
first place, an invitation for confusion. In places where DCONVERT had assumed a logical variable,
it had marked it in the source, and any other doubtful bits as well, although it would sometimes
miss colons when they were neither in drive assignments or text. None the less, I converted. acres
of files this way, and the majority worked straight away. The only pay was that DCONVERT didn’t
convert the STORE type assignments to ‘=’ type assignments, I ended up doing that by hand
There are many other differences but they are mainly insignificant in nature, the extra power
of DBIII and DBIII+ comes from the new facilities, these are many and overcome a lot of the
deficiencies of DBII. Take for instance the lack of fast subroutine calls (procedures) in DBII. To
use a procedure, you wrote a separate little program to do your procedure bit, then told DBII to
The problem was, that as the program was interpreted, and to keep the memory utilisation low,
DBII read the program from disk as it went along, it had to drop the current part of the program,
open the new procedure file, do it, close the file and the carry on with what it was doing before
the procedure turned up. All very disk intensive and slow particularly if the procedure was inside
a loop of some kind.
In fact from an operating speed port of view, DBII actively discouraged the use of procedures.
DBIII and DBIII+ introduced a new idea. Again to keep the memory utilisation under control, the
program is read from disk as before, but (a maximum of 32) procedures can now be grouped together in
one file and opened before the program starts. As this file is opened, before the program starts,
and not closed afterwards (unless you have a number of ‘procedures’ files and therefore open
another) the whole process becomes a lot less disk intensive.
Another area DBII was deficient was the fact that only two databases could be opened at
the same time. With DBIII and DBIII+ up to ten databases may be opened at once, but care as to the
total number of open files (program files, databases and indexes) must be exercised. With up to 10
databases open, sorting out which one you’re actually using at one time can be fun, so a system
of aliasing has been devised. You can either refer to a database by its name, or by its alias,
which may be assigned when the file is opened. There are some rather clever relational linkages
between databases which are allied to this ability of having a number of databases open at once (I
haven’t had cause to use the yet, so I can’t tell you if they work).
Another mayor change is the increased number of variables (256) and the use of local variables
within procedures, a bit C or Pascal-ish that, but it can catch the unwary. Unless a variable is
declared PUBLIC at the start, or declared before it’s passed to the procedure or passed using the
DO <procedure> WITH <vars list>
command, followed by a matching PARAMETERS command in the procedure, strange things happen, and
variabies which would have been passed under DBII don’t get passed under DBIII. On the whole this
is change for the better but takes a little getting used to, particularly if you are converting
Programs and unaware of what’s going on.
The maximum number of fields, the field lengths and numbers of records have all grown and are
now large enough for even the most ambitious space gobbler.
As DBIII and DBIII+ are up-market products, all sorts of nice goodies have been bolted on, the
SET COLOR commands are useful from a sales point of view, punters always like to see Technicolour
screens even if they are constrained to black and white. Some nice box drawing functions have been
added to DBIII+ and with a bit of cleverness ‘windows’ become possible. Calls to machine code
routines, missing on DBII (MS-DOS version) and DBIII have been put back albeit in a different form,
and of course, DBIII can ‘Run’ other programs from inside itself (see
DO WHILE loops have gained an EXIT command, so that a DO WHILE .t. can be exited with ease from
inside a CASE statement (possible, but messy using DBII). On the subject of loops, a FOR .. NEXT
loop has appeared.
A couple of new data-types have appeared (apart from formalising the logical data-type), a
‘date’ date-type, and the memo field in the database. The ‘date’ data-type automatically does the
Julian date conversions from a date and back again, whist the memo field saves database space where
the occasional large comment may be required. The memo field links with a second database and