IAN'S QUEST

BY IAN CHADWICK

One of the sure paths to success in the software world is to boldly go where everyone has gone before, to paraphrase Star Trek's opening line. After one brave soul has broken the ice with some daring effort, many others like to jump in and share the water.

So it's been with dBASE, Ashton-Tate's remarkably popular database manager for the PC world (actually, it sprang from that crusty but much-missed dinosaur, CP/M). Lots of dBASE clones, compatibles and contenders have emerged from the woodwork, few able to garner more than a small share of the market. That hasn't stopped many from trying. Database managers are among the most important programs available, and there's considerable room for variation and improvement.

What made dBASE so well received? For one, it broke free from several traditions and gave the user not only an application—the database manager itself—but the tools by which the user could also change the application. dBASE is not merely a program, it is a language and an interpreter. You can use it "as-is" or write your own database manager, report printer, field display and so on.

dBASE got an undeserved reputation as a difficult and unfriendly program, a reputation Ashton-Tate worked hard to overcome. They improved the front end by giving it the "Assist" menu/dialog box interface, improved the report and label-creation programs and over the generations added a wealth of commands and functions.

dBASE's, language isn't on a par with mega-languages like C; it's rather simple in comparison. Its focus is data: strings, fields, reports, output. In syntax it's rather like BASIC, and anyone with even a rudimentary experience in BASIC will find it relatively easy to write programs in dBASE. Many of the commands are, if not identical, similar. You can enter many of the commands directly or write them into stand-alone programs.

And dBASE is quite flexible, tolerant of faults and bug-free. One example is its ability to change the database format after it has been created. Even with a large database stored, it is simple to add or delete fields, change field sizes, modify reports and resort the data—without losing anything or crashing the program.

In response to user comments, dBASE's user interface has changed to suit more of the casual or novice users. With pull-down menus and pop-up dialog boxes, it's pretty simple to use. If your tastes run more to the dry functions, simply press Escape and you're in the command-line interpreter. For that matter, there's much more power in the command structure than the user interface allows. It's well worth learning how to use it.

For the ST, the dBASE clone is dBMAN V, from VersaSoft. It has evolved over many versions, including an early one marketed by Atari itself. The back of the dBMAN V manual claims it has "all the power of dBASE III + and more on your Atari ST!" That's a mighty impressive claim, one I wouldn't want to defend as literal in court.

Lest you get led astray, dBMAN is not 100% dBASE III + compatible. It reads the .DBF database files but has problems with dBASE indexes ("Error 39 line 6 program CMDLINE.RUN."), even with SET DB3 ON. It also won't load dBASE II report and label files, and several dBASE commands are not supported or require a substitute. The user interface is similar to but not the same as dBASE.

My first experience with dBMAN was less than impressive. I tried to read a dBASE III file from drive A, got a disk I/O error and the program crashed. Nastily. From that moment on, it refused to load the "assist" program, the menu-driven user interface, and it crashed back to the desktop every time I tried. I copied a few files from the original disks, but it still crashed. Finally I gave up, erased the lot and copied the original back over again—every single file. Two bombs again the next time I tried. Sigh. I rebooted and tried again. After a lot of disk chunking, it finally worked.

That's not a good way to begin a relationship. dBMAN also takes what seems an endless time to load files and overlays. This is due in part to the glacial speed of the Atari file I/O itself, but I'd hazard a guess that their code could be optimized and some gain in speed achieved. Speed is one of the great bugbears of data processing, and the faster the program works, the happier everyone is. dBMAN seems to have a lot of overlays, too. It's 300K-plus but spends a frightening time loading overlays.

If you look in the documentation index for the SET commands, you won't find them. That's odd. There are a lot of them—44 by my count. A little digging through the manual showed me that the nearly 150 functions (as opposed to the commands) are not listed in the index either. Nor are the MODIFY, SHOP, REPLACE, and a whole lot of other commands. Combine this with a lack of a master tutorial and tutorial, and the manual comes across as one of the weakest links in the package. Fortunately, because of its closeness to dBASE, a wide variety of third-party books can help provide generic information, although they can't repair the manual's flaws.

Okay, so I finally loaded my dBASE file into dBMAN. So far, so good. The database appeared to arrive intact (all 40 records). I tried to index the database. The result: "Error 11 line 6 program CMDLINE.RUN. report to VersaSoft." Great. Then it said: "Error 12 line 96 program CRINDEX.RUN." Then "Error 12 line 113 program A. RUN," "Error 11 line 58 program ASSIST.RUN." And instead of returning to Assist, where I'd been when I left, it went back to the command level. So I typed "Do Assist" and got the message "Err 11—A Disk Read Error has Occurred."

Error 11 in the manual says "check if the disk is operational. Check if the diskette is in place." Okay, I quit and checked. Yep. Both okay. Other programs work fine. Back into dBMAN. Try to create an index again. Oops. This time I'm told "Sorry, but that filename exists." That's okay; I want to overwrite it (the file has zero bytes). Nope, it won't let me. I have to enter a new filename.

Whatever caused my first problem disappeared, and the index is generated without any error messages. Fine. I close the database and open a larger one: 222 records. It appears to load fine, but when I tell it I want to edit record 222, I'm told "Record 222 is not in the database file." But I can go to 221 and use Control-N to get there. The record number clearly says 222. When I use Locate and select Bottom, it finds record 222. What's wrong?

Oops. I accidentally selected modify rather than edit. I get a dialog box with "Create one/use existing one." There's no cancel option. What if I don't wish to do either? Escape and Undo won't work. I have to wait until I get to the file selector before I can cancel. Not very friendly. A lot of boxes need this sort of addition. And why do some of the pop-up boxes allow mouse selection while others require that I use the keyboard arrows?

Okay, so I want to edit a record. I can enter a record number or accept "0" for the current one. But what is the current record number? It doesn't say. Just have to hope it's the one I want.

Let's create a report. I want to call it "SRT," the same name as my sorted database. When I enter that name, I'm told "File already exists. Use MODIFY REPORT." So I go through the tedious process of getting back to Assist and select Modify Report Form. But there is no "SRT.FRM" showing in the file selector! Grrr...

Back to the report generator. All I want to do is create a simple report of the book titles in my database. I enter another report name (why?). A lot of disk chunking again. Sigh. Now I have to enter the master database name. Huh? I wanted to use the one I had open in Assist. And during the report process, I keep having to specify the database name. How many times must I tell it? Every time I insert a field, obviously.

I'm very familiar with dBASE; I've used it for a couple of years and written databases, reports, etc, for the likes of the University of Toronto. I can create a dBASE report in my sleep—it's that easy. But confronted with dBMAN's report screen, I'm stymied; it isn't an intuitive process. I have to dig into the manual for help and find myself hacking and experimenting because the descriptions and screen shots are not useful or complete.

The report generator is powerful, lots of commands and flexibility, but confusing. There are tutorials for reports and labels, but they're weak; they offer step-by-step help, but not always the reasons for your action. For example, when you create a report or a label, you are asked for a master database file and a master index. In all three tutorials you're told you don't need a master index. Why not? I can't find any other references about using a master index in the manual. But dBMAN asks. It's this sort of thing that adds to the aggravation.

The output tutorials discuss only the direct command-line entry method, rather than the menu-oriented system.

Now in my opinion, ST users will prefer to use a menu-based system; otherwise they would have bought a PC in the first place! Since dBMAN is available on several platforms, I assume the command-line entry is how they get around having to write multiple manuals. An ST-specific manual is provided, but I can't see that it's very ST-oriented.

In dBASE I can reassign the function-key definitions. I don't think I can in dBMAN. I can't find any reference to it in the manuals.

When I tried to convert a dBASE file, I was thrown back into the GEM desktop with a converted file zero bytes in size.

dBMAN is a diamond in the rough, but it has a lot of problems, mostly in its cumbersome dependance on overlays, the clumsy user interface, the unpolished screen displays, glacial disk I/O and mediocre manual—things that, if cleaned up, would improve the program 1,000%. It's also not bug-free, something I expect from a company that's been slogging away so long at a program.

On the plus side, it is a powerful and flexible database program with a lot of muscle. To get to that core, you need dedication, perseverance and faith. It's certainly the most fully featured database manager available for the ST, and the wealth it offers is undeniable. I just think they could have made it easier to get to it all.

Overall, I'm unsatisfied. The program doesn't feel polished or even entirely finished, not the feel of a thoroughly professional product. Against the competition (Data Manager ST, Superbase and Regent Base), its weaknesses balance the features so that it doesn't offer a significant advantage over the others beyond the dBASE file compatibility. I need more dBASE compatibility—indexes, forms, labels—before I move my working files from the PC to the ST, not to mention greater speed and a smoother interface. Maybe I'll have to wait for dBMAN VI.

By now you probably know about Dy-naCADD 1.5. ISD deciding to release 1.5, a significant upgrade, rather than bring 2.0 out yet. They're concentrating their efforts on producing a multi-platform CADD product, including IBM, Mac and Unix. But DynaCADD on the ST needed—and deserved—improvement. So programmer Dave Fletcher spent many, many hours rewriting code so that 1.5 could come about.

Version 1.5 adds many new features, including Bezier and b-spline curves, hatching, sectioning, a vector font editor (and ten Compugraphic fonts), 2-D solid fills, major and minor grid and axis marks, named layers, measure area command, filletting between arcs, background plotting, Postscript support and more. They also reduced the program size by using overlays and managed to make loading them fast enough as to be almost unnoticeable. DynaCADD 15 now works comfortably without accessories on a 1040 ST. The new version is also streamlined, with several unnecessary features, such as "Suspend," removed.

A lot has gone into this version, even a major manual overhaul, to the point of eliminating the criticisms I had in my review (co-authored with Thorn Weeks). I recommend that anyone who is a serious CADD user and who hasn't picked up on DynaCADD yet get this new version. It's a super program, and the only professional CADD package in the market.

A while ago, I received a small book about the ST, called The Atari ST Book, by Ralph Turner. Since it is more or less a beginner's book, I didn't pay it too much attention. However, in the past months the book has become a minor celebrity among a small group of novice users here. Unhappy with their official documentation, I recommended they take a look at Ralph's book. Many of them have found it helpful. It's full of useful hints, tips and information the Atari manual either misses or glosses over. There is some peripheral stuff, to be sure, including software-specific discussions that are dated, and I don't agree with his negative view toward protected software; but over-all it's a good buy and has a nontechnical approach, without talking down to the user. Recommended.

Quick test. What's wrong with this line, found on the back of Michtron's Personal Finance Manager:

"It's GEM interface allows transactions to be entered or altered as easily as filling out a form."

Got it yet? The possessive of "it" is "its." "It's" is the contraction for "it is." If you failed this test, do your homework. The next test is on the passive voice.

Ian Chadwick is a Canadian freelance writer and editor whose hobbies include writing about, reading about and exploring the use and abuse of the English language. He is also an amateur paleontologist, naturalist and carpenter.