|
|
|
|
|
|
|
|
Some Linux aficionados would like to run their DOS-based xBASE database under Linux. Robert Broughton examines two products that make this possible.
by Robert Broughton
XBASE is a generic term for implementations of what was originally the dBASE programming language. The principal players in the MS-DOS portion of this market are FoxPro (Microsoft), dBASE V (Borland), and Clipper (Computer Associates). It is a language which has statements normally found in programming languages, like IF, ELSE, ENDIF, and WHILE. (There is a GOTO statement, but it is for going to a specific record in the file; There is no GOTO in the FORTRAN flow-control sense.) It also has some powerful statements for processing files and getting data from screens. Setting up relations between files is easy to do. The names of all fields in a file, and their types and lengths, are recorded in the file header. New fields can be added to a file without changing programs which use the file.
None of these products are available for Linux, although there has been at least one effort to make the SCO version of dBASE V work with iBCS. What we have instead is FlagShip from multisoft Datentechnik GmbH and dBMAN from Versasoft Corporation. Both of these products run on several implementations of Unix; dBMAN also runs on MS-DOS.
These two products resemble each other only at the very simple level. To start with, FlagShip is patterned after Clipper version 5, while dBMAN resembles dBASE III+ or FoxPlus, with some enhancements. This, in turn, means two things. FlagShip, like Clipper, is a compiler, while dBMAN is primarily an interpreter, although it is possible to "compile" dBMAN programs (though not into binaries). FlagShip is also an object-oriented language, which makes it philosophically different from dBMAN, as well as from FoxPro and dBASE. Clipper and FlagShip have a lot of C-like features, which I suspect won't be a problem for most Linux users.
Their target markets are also different. dBMAN is targeted primarily at individual users. If you want a program you can run on your desk to keep track of time billed to clients, or that will maintain a data base of customers or your inventory, dBMAN will do the job, but FlagShip might be overkill. FlagShip is aimed at people who want to develop or port software packages.
I consider four features to be essential for developing decent user interfaces: pull-down menus, windowing, hot-key activated selection lists, and input validation. These products were evaluated with these criteria in mind. I'm also in awe of FoxPro's BROWSE command, so it's the standard by which I measure the browse features of other languages.
As I mentioned previously, FlagShip is a compiler. It translates the xBASE code into C, and the result is turned over to the gcc compiler. (Yes, you can link functions written in C or assembler into FlagShip programs. You can even mix xBASE and C code in a program.) The compiled binaries may be distributed without paying royalties to multisoft.
FlagShip has no equivalent of the "dot prompt" or interactive command interface found in other xBASE products. However, there is a public-domain program in WorkGroup Solutions' FTP area named dbu . This program will provide the capability to create files and indexes, add, change, or locate records, and browse files.
The FlagShip feature I like best is its on-line reference program called fsman. fsman contains the entire FlagShip manual, over 1,000 pages worth of material. If you use an X-window environment, you can easily park fsman in one corner of your screen, and refer to it whenever necessary. It's also possible to save pages of the manual to ASCII files, which makes it easy to incorporate programming examples in the manual into whatever program you are working on at the time. Of course, you could also use the mouse to copy text from fsman into your program.
When you install FlagShip, you get a set of terminfo files specifically for FlagShip. Because of a problem with ncurses 1.8.5, they are compiled with ncurses 1.8.1.
FlagShip doesn't have a function specifically for managing pull-down menus. What FlagShip and Clipper programmers normally do is use @PROMPT/MENU TO statements to create the horizontal menu, and use a function called ACHOICE() for the vertical menus.
FlagShip has functions for managing windows that work very nicely, but they're not part of the basic package. You have to buy the FStools library. As the name suggests, the FStools library is a clone of the Clipper Tools library. There are also windowing functions in the NanForum library, which is public domain.
Hotkeys are set up with the statement SET KEY keyid TO statement. Normally, statement would be a function invocation. Within this function, you can call the function READVAR() to find out which field the cursor was in when the key was pressed.
An input field can be validated by adding the VALID statement parameter to the @SAY/GET statement. Again, the statement would normally be a function invocation. Within the function, the value the user typed in could be looked up in a database file.
To determine how compatible FlagShip is with Clipper, I downloaded a couple of programs from a local BBS. I ran into two problems. The programs contained function calls that looked like this:
IF (expr, true_result,)
FlagShip complained about the absence of the third parameter. Adding ".f." for the third parameter solved the problem. The other problem was a reference to a function named FT_Shadow(), which FlagShip simply doesn't know about. I got rid of this problem by commenting it out. Once I got clean compiles on these programs, they worked beautifully.
A key feature of FlagShip is the TBROWSE() object. You use this in place of the BROWSE command that exists in other xBASE languages. If you don't have any previous experience with object-oriented programming, setting up TBROWSE() for the first time is intimidating. However, I was able to get it to do what I wanted by extracting the example in fsman and rearranging it.
I encountered one problem with FlagShip when I was running a FlagShip program in an xterm; I got hieroglyphics instead of line drawing characters. Fiddling with the "acsc" parameter in the "fslinxterm" terminfo entry had no effect whatsoever. I worked around this by using the "vga" font that comes with DOSEMU. I eventually learned that instead of using the acsc parameter, FlagShip uses another file named Fschrmap.def which maps the character codes generated by the program to the character codes displayed on the screen. I didn't bother to alter this, however. Using the "vga" font is actually a better solution, because it's possible to display double line drawing characters.
Another "gotcha" in FlagShip turned up when I put a REPORT EDIT statement in a program; The compiler rejected it. It seems that this statement just doesn't exist in the Linux version. REPORT FORM will work if you have an MS-DOS version of Clipper around to set up a report. REPORT EDIT does exist in other implementations of FlagShip, and I've been told by WorkGroup Solutions (the North American agent for FlagShip) that it will be in the next Linux release.
Another problem had a number of people scratching their heads for a while. ACHOICE() and several other functions were simply refusing to work. It turned out that the name of my program was browse.prg, and browse is treated as a reserved word by FlagShip. I can report that the support people at multisoft and WorkGroup Solutions were reasonably helpful in resolving this problem.
WorkGroup Solutions is very aggressive at marketing their product. (They also sell a Linux CD-ROM.) They turn up quite frequently in the comp.language.xbase and comp.os.linux.misc newsgroups. They promise that FlagShip will eventually have some sort of GUI support. Programs that have been ported, or are in the process of being ported to FlagShip include:
WorkGroup Solutions also happily points out that FlagShip programs could be attached to WWW pages, making it possible for net surfers to access and update databases.
dBMAN functions primarily in interpretive mode, although it is possible to compile programs. (Compiling a program does not produce an executable binary; It produces a .run file, which still requires dBMAN to execute it.) When dBMAN starts up, a CMD: prompt appears at the top of the screen. At this point, you can type in ASSIST, which starts up a menu-driven interface similar to ones available with FoxPro or dBASE, but limited in comparison; dBMAN's ASSIST only allows one file to be open at a time, which in turn means that it is not possible to set up relations. It is possible to start up a simple program generator from ASSIST. Again, it has a single file limitation.
It is also possible to enter CREATE REPORT or MODIFY REPORT at the CMD: prompt. This will put you in dBMAN's report writer, which works very nicely. The report writer allows relations. I had a little bit of trouble getting it to write a report with lines wider than 80 columns, but I eventually got it to work.
dBMAN provides a function called PMENU() to create pull-down menus. PMENU doesn't have any mechanism for temporarily disabling a menu choice.
dBMAN handles windows differently from other xBASE products. Prior to defining a window, you call PUSHWIND() to push the current window onto a stack. (When a program is in its initial state, the entire screen is considered to be a window.) You then call WINDOW() to create the window. When you are finished with it, you call POPWIND(), which removes the window, and makes the previous window active.
dBMAN allows you to define only one hot key. You do so by invoking the ONKEY( ) function. This will have no effect until you execute the statement ON KEY statement. (statement will normally be DO hot-key-handler.)
The BROWSE Command has a long list of options. You can browse only certain fields, and you can specify the width of each field, and whether it is editable. The list of fields can include fields in other files, which is great if you have relationships set up.
dBMAN does not use either termcap or terminfo. Instead, it includes a file named dbmterm.dbm. It looks a lot like termcap. The first problem I had to solve after installing dBMAN was that there were no entries for either "xterm" or "console".
I created one for color xterms without a whole lot of difficulty, and it is included in Listing 1.
dBMAN has no facility for executing functions written in C or assembler.
There were a couple of nasty bugs in the version of dBMAN I evaluated, which was 5.32. The main one was that procedure files simply didn't work if the procedure file was a .prg. If you compiled it into a .run file, it worked OK.
I put together a simple benchmark program, which can be found in Listing 2.
The test file I used contained 33,830 records. I ran the benchmark with dBMAN (compiled and non-compiled), FlagShip, and FoxPro 2.0 under MS-DOS. The benchmark was done on a 66MHz 486 with a SCSI disk. Here are the results. At first glance, you might conclude that both dBMAN and FlagShip were blown out of the water by FoxPro. This would be unfair. FoxPro generally beats similar MS-DOS products in benchmarks, because FoxPro, by design, grabs all resources it can find. No well-behaved Linux program would do this. To put it another way, dBMAN and FlagShip would run a lot faster if they allocated most of the 16 megabytes of memory on my machine, but someone doing text editing on another terminal would see their performance suffer.
xBASE files always have separate data (.dbf) and index files. The format of data files is pretty much uniform for all xBASEs, but as far as I know, no two xBASE products use the same index file formats. I was able to use the same .dbf files with FlagShip and dBMAN, but I haven't tried any memo fields yet. (Memo fields put free-form text into a separate file, usually with the .dbt extension.)
Robert Broughton has been developing software for 23 years, and has been using Linux since February, 1993. He is employed by Zadall Systems Group, in Burnaby, BC, Canada. He can be reached by e-mail at a1040@mindlink.bc.ca.
