dBMAN Tutorials #1 in a Series General/Bug Report by John C. Leon August 20, 1986 distributed through the H.A.S.T.E. BBS Houston Atari ST Enthusiasts 713-955-9532 permission granted to distribute unaltered original text There are precious few serious databases on the market at present for the Atari ST. The majors are dBMAN, the Manager, and Zoomracks. H&D Base is a dead horse, as Mirage has appparently gone out of business. Others will come. This series of articles concentrates on what appears to this writer to be the single most versatile and powerful program, dBMAN by Versasoft (versions 2.00L and 2.02L are included in all remarks, with known differences pointed out). We assume you have a working knowledge of relational databases, and have made some effort to use the product. For those who have never used a dBMAN or dBASE type of command-driven relational database, I urge you to buy a book or two on dBASE programming before tackling any heavy-duty work with dBMAN. The two products are very similar, but far from directly compatible, despite consistent claims by reviewers and any ads you may see. Compatibility between dBMAN and dBASE extends only to the ability to use the CONVERT command in dBMAN to convert a dBASE data file to dBMAN format. Command files (programs) written in dBASE will not run in dBMAN without modification. The syntax of the two languages is different, and there exist commands in each language that do not exist in the other. Suffice it to say that the commands are similar enough to make the porting of programs relatively easy. The dBMAN documentation is pretty stiff. It is packaged in an attractive slipcase and three-ring binder, containing logical sections: basic, advance, reference, commands, functions, appendices and index. However, the level of detail leaves a lot to be desired. You are often merely presented a brief description of a command or function with no explanation of its power or usefulness. The SET RELATION TO command is incredibly powerful, but it receives the briefest of treatment (two pages - long by Versasoft's standards!) and no hint is given on when it would be useful. Versasoft seems to assume that users of the product already have a great deal of savvy on power programming of relational databases. I would define their entire manual as a technical reference piece. dBMAN Tutorials - 1 - General/Bug Report BUG REPORTS 1. The main dBMAN screen display is unstable, but this does not appear to affect its performance. The status line (the one that appears in inverse video), is prone to self-destruct, disappearing in whole or in part without any reason I can find. Printing a report causes the same few garbage characters to appear in the left section of the status line every time without exception. If these kinds of obvious problems exist in something as basic as displaying a screen, what other bugs might there be? 2. The Report Generator 2.1. The first screen of the report generator indicates that you can use the PgDn keys (CTRL-D) to move between screens. You are also told that CTRL-D is used to delete a field you no longer want in the report. Wrong. It's CTRL-E that erases a field. Version 2.02L's report generator does specify use of CTRL-E. 2.2. I discovered a problem in changing report formats with the MODIFY REPORT command. As you modify the format, you naturally see your keystrokes reflected onscreen. However, if you then save your changes with CTRL-S and immediately try to print your modified report, you may find that you get the OLD report format!! I have found that after modifying a report, you must exit dBMAN to the desktop and reboot the program before report modifications "take". 2.3. If you specify a footer in your report, you will find that your footer string will always butt up against the last line of detail on each page of a report. In other words, there is no blank line between the body of your report and a page footer. There is a way to work around this problem (see dBMAN Tutorial #2). 2.4. On the screen where you specify any groupings desired, you are asked if you want a page eject after each group. Regardless of what you specify, you will NOT get a page eject. To get a page eject, you must not only answer yes, but must have a group footer! If you don't want a group footer, specify a group footer string of ' ' (a blank space in single or double quotes). This is sufficient to give the program what it needs to give you a page eject - a group footer of some kind. 3. Procedures 3.1. Version 2.00L (the original ST version) can refuse to acknowledge your procedures if you have them in folders, or on a drive other than the drive you booted from, even if dBMAN Tutorials - 2 - General/Bug Report you have used the SET DEFAULT TO command to reset a default drive and directory. What happens is that the SET PROCEDURE TO command does not preface your procedure's file name with the default drive and path. Version 2.02L (available for $10 plus your original disk) fixes this. 3.2. Be extremely careful in your choice of a text editor to use in writing your command files. All of my programs created with the Final Word worked perfectly, until I began to use procedures. Apparently the SET PROCEDURE TO command forces a search of your entire procedure file, so that dBMAN can set up its internal procedure table. If you have any non-ASCII characters in the procedure file, dBMAN will promptly dump you to the desktop. I've learned that Final Word puts a non-ASCII character as the very last byte in the file. That one odd end-of-file byte is sufficient to kill your program entirely. I now use another editor. As additional bugs become known, we will inform you in separate articles. Let us know of any problems you have experienced. We will investigate them and advise other members and potential purchasers. I wrote to Versasoft on behalf of the club on July 22, 1986, requesting information on our ability to update to version 2.02L, and requesting any additional information on known bugs and workarounds. After all, their own manual suggests that if users have problems they should contact their dealer or local user group. This is a self-serving statement at best, but we do not object as long as the company shows us some consideration by supporting the group. As of this date we have not received a response. SUPPORT In this writer's opinion, Versasoft's support is good. My several calls were always returned. I got help with several troublesome problems I had. The third time I called I was politely asked to send in $25 for support (they keep track!), but they did answer my question. When I first asked about an update policy for holders of version 2.00L, I was told there was none. Version 2.02L only had internal program changes. A few days later I was told by the same person that I could get an update for $10, and that some problems with the SET PROCEDURE TO command were cured. Get the update. It's well worth it, as the SET PROCEDURE TO command is very important, and in Versasoft's own words, is "all screwed up" in version 2.00L. Versasoft's current address and phone numbers are: 4340 Almaden Expressway #250 San Jose, CA 95118 general phone 408-723-9044 dBMAN Tutorials - 3 - General/Bug Report support phone 408-723-8384 As of July 1, 1986, Atari has the marketing rights to dBMAN. Versasoft is still the developer and source for support. The dBMAN runtime package remains available direct from Versasoft for $149.95. This series of articles is anticipated to constitute H.A.S.T.E.'s primary avenue of support for local dBMAN users. Many topics will be covered. We will not hold your hand, though, so please invest some time in learning the product - we can't teach you to read the manual (life's tough!). What you WILL get is a high level of responsiveness to particular problems, comments on functions and how to use them, expanded narrative on key concepts of database design, etc. The next tutorial will cover the report generator. dBMAN Tutorials - 4 - General/Bug Report