Scor­pio News


October–December 1987 – Volume 1. Issue 4.

Page 42 of 55

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 afterwards.

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 ‘DO’ it.

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 last article).

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

Page 42 of 55