Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!van-bc!rsoft!mindlink!a1040 From: a1040@mindlink.UUCP (Robert Broughton) Newsgroups: comp.sys.amiga Subject: dBMAN V Review (long) Message-ID: <4010@mindlink.UUCP> Date: 2 Dec 90 02:29:43 GMT Organization: MIND LINK! - British Columbia, Canada Lines: 163 dBMAN V by Robert Broughton One of the reasons why the Amiga has not been taken very seriously for business usage is the lack of a dBASE-compatible product. The dBASE world is big; There are at least six clones of the original Ashton-Tate product, entire catalogs of add-ons and application programs, and several monthly magazines. There are versions of dBASE or clones thereof for Macintoshes and XENIX systems. Despite the fact that there are several Amiga programs which read and write dBASE-format files, only one dBASE clone exists for the Amiga, dBMAN from Versasoft Corporation. Until recently, dBMAN used a file structure unique to dBMAN, which limited its usefulness; It qualified as a dBASE clone only because it is an implementation of the programming language. dBMAN V addressed this file compatibility issue by providing a configuration option, DBASE3, and a SET option, DB3. Enabling this option is supposed to make dBMAN work with dBASE III- compatible files. Unfortunately, this doesn't quite work. Logical fields are expected to contain values of "Y" or "N" instead of "T" or "F". If a field contains anything other than "Y", its value is considered to be .F. This was the first of several serious bugs that I found in dBMAN V. Here is a list: - A logical expression such as "choice > 3" will be rejected by the parser, but "choice>3" is accepted. - Attempting to use the RUN command will cause a visit from the Guru. - The record locking feature doesn't work. I got a curious answer when I reported this to VersaSoft; The multi-user commands and functions don't do anything because they are not "hooked" to a multi-user OS. Well, maybe, but if this is the case, the function RLOCK() should always return a value of .F., instead of always returning a value of .T. I'm also curious about what would happen if this product were used on a LAN, especially a LAN with a mixture of hardware. - An advertised capability for calling assembler functions doesn't exist. This is a real shame, as it makes it impossible for dBMAN to interface with AmigaDOS, Intuition, or ARexx. - AmigaDOS's standard blue/white/orange color combination is fine for graphics applications (although Commodore is getting rid of it in release 2.0), but it looks terrible for text applications, which is what dBMAN is. dBMAN V contains a SET SAY/ERASE/GET VIDEO command which is supposed to change the pens that dBMAN uses, but this command doesn't work. Since dBMAN V opens its own screen, the various PD tools for changing colors can't be used. There are also some important incompatibilities with other dBASE products, which VersaSoft does not regard as bugs: - When a numeric field from a file is displayed with an @...SAY command that does not have a PICTURE keyword, dBMAN displays 17 digits, instead of using the length defined for the field. - The FUNCTION keyword for @...GET commands does not exist. Describing problems like this is only part of the story. The supplied ASSIST program, screen generator, and text editor are horrible. Fortunately, in the case of the text editor, it is possible to substitute other text editors for the supplied one. The product is generally very inconsistent about keystrokes used for navigation in commands such as BROWSE, EDIT, DISPLAY, etc. Given the general balkiness of the product, one could easily ask, why bother with it? Well, I use it because I need it, and it's the only product available that fits the need for a dBASE language and file compatible product. It IS possible, once you learn its many idiosyncrasies, to do useful work with it. For one thing, it's no slouch in terms of performance. I ran two benchmarks. The first one looks like this: @10,0 SAY "Start" n1 = 0 DO WHILE n1<1001 n1 = n1+1 ENDDO @11,0 SAY "Finished" This takes about three seconds on a standard Amiga 2000. When run under FoxBase+ 2.10 on a Commodore PC 40-01, it takes about a second. (The PC 40-01 is an AT clone, with an 8 mHz clock and a data transfer rate of 400-500 mb/sec; The Amiga used here has a GVP disk controller, which has about the same data transfer rate. It should be understood that FoxBase is a very fast product. A more sophisticated benchmark copies three fields of a files containing 2,600 records to another file, then sorts it; The resulting file is named "temp2". Another file, named "event", which contains 2,500 records, is indexed. Then, for each record in "temp2", a SEEK is performed on "event". If the SEEK is successful, some data from the record found is "printed". (For the purpose of the benchmark, the output is sent to a disk file.) Regardless of whether the SEEK is successful, some data from "temp2" is also printed. There is also some code for counting lines and printing headers. This program takes seven minutes and 20 seconds on the Amiga 2000, and five minutes on the PC. However, the files on the PC are about 10% smaller. The dBMAN programs were compiled first. Also of importance is that very little work was required to make a program written for dBMAN work with FoxBase. The format of dBMAN's SELECT statement is different. Instead of "SELECT" followed by a work area number, it is "SELECT" followed by a "file ID", which is "FP" for the primary area, and "FJ", "FK", etc. for secondary work areas. When referencing a field in another work area, instead of "alias->field", you must specify "FJ.field". To convert from dBASE, FoxBase, or another clone to dBMAN, however, you will have to deal with specifying PICTURE keywords every time a numeric variable is read from the screen, displayed to the screen, or printed, a very tedious chore. dBMAN V has some other positive aspects. It multitasks properly. There are very useful extensions for handling vertical menus, horizontal menus, scrollable menus, and Amiga-style pull-down menus. There is a capability for handling arrays, although the designers chose to use []'s for subscripts instead of ()'s. (Clipper uses []'s also.) The report writer is powerful, although plagued with the sort of idiosyncrasies found elsewhere in dBMAN. Numeric fields will be displayed as 17 digits unless you tell it otherwise. When a field from a file is selected to appear in a report, the field is defined in the form "filename->field". If you leave it this way, your report will work only with "filename". This is often undesirable, as you may want to sort the file before generating the report. You can get around this by editing out the "filename- >". The really unfortunate thing about this product is that the really serious shortcomings in it could be fixed in a matter of a few person-weeks. Versasoft cannot use poverty as an excuse for not doing this. The Amiga version comes with an 80-page, glossy- covered supplemental manual. The material in this manual is of little importance, and could have easily been put in a "read.me" file instead. One other suggestion for Versasoft; Although dBMAN can now read and write dBASE-compatible files (provided that you use an intelligent text editor to change "T"s in logical fields to "Y"s), index files still have a format unique to dBMAN. A configuration option which would make it possible to work with the type of index files used by Lattice's dBC III product would be a great help. ----- Permission to reproduce all or part of this article granted as long as credit is given to the author. -- Robert Broughton a1040@mindlink.uucp a1040%mindlink@wimsey.bc.ca a1040%mindlink@van-bc.uucp