Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!netcom!rodent From: rodent@netcom.UUCP (Richard Noah) Newsgroups: comp.sys.amiga Subject: Re: dBMAN V Review (long) Message-ID: <18025@netcom.UUCP> Date: 4 Dec 90 04:17:09 GMT References: <4010@mindlink.UUCP> Organization: Netcom- The Bay Area's Public Access Unix System {408 241-9760 guest} Lines: 173 As the "Amiga Programmer" and tech support person for VersaSoft, I would like to post an unofficial response to the recent review of dbMan. If you couldn't care less about dBase3+ clones, hit 'n' now. For those of you interested... a1040@mindlink.UUCP (Robert Broughton) writes: >dBMAN V >by Robert Broughton >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 is just plain wrong! Amiga dBMan supports "Y", "N", "T" AND "F", with or without the dBase dots ". .". Perhaps you have an ancient version Robert? >This was the first of several serious bugs that I found in dBMAN >V. Here is a list: If you find bugs in our product, please let us know about them and give us a chance to fix them our explain them before blasting us in public! Thank you. Many of the things you mention have already been fixed, as I detail now: >- A logical expression such as "choice > 3" will be >rejected by the parser, but "choice>3" is accepted. No, both work fine! >- Attempting to use the RUN command will cause a visit from >the Guru. No, this works fine. Were you trying to run something larger than available memory? dBMan is a very large program. >- 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 Naturally! We can't support what isn't there! >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. Hey, you shouldn't be using those, right? This isn't a "bug". >- 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. I don't think we ever advertised this, because we've never even considered doing it. If you need DOS access, we support it with high-level functions. If you want complete Intuition support, get an Amiga-only product. Remember, our interface is STANDARD across 41 platforms, from ST's to mainframes. If we started customizing to a particular OS, all hell would break loose. If you want Arexx, ASK US for it! As a old-timer Amigoid, I would LOVE to add an Arexx port, but the boss won't let me unless people express a desire for it (desire == sales). >- AmigaDOS's standard blue/white/orange color combination 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. V 5.3 (recently released) supports any resolution, any palette, any number of colors, any size window (even on the workbench screen!) and FULL support at the high level. Again, please check with us before griping in public! >There are also some important incompatibilities with other dBASE >products, which VersaSoft does not regard as bugs: Let us know about these, and we WILL fix them. Really, nobody has complained! >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 ASSIST program is STANDARD, relatively friendly and the text editor is only for people/platforms that don't have a real editor (kinda like "ed" in AmigaDOS, nobosy really uses it except as a last resort or for a quick small change.) >The product is generally very inconsistent about keystrokes used >for navigation in commands such as BROWSE, EDIT, DISPLAY, etc. Again, we're being STANDARD across all 41 platforms. The keys really aren't very difficult to use, and they're always displayed on-screen. >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. A great many people, even large companies, mostly outside the US where the Amiga is taken more seriously, use Amiga dBMan for SERIOUS use. We get big orders from around the world, especially Germany. >For one thing, it's no slouch in terms of performance. I ran two now it's even faster... V 5.3 is between 50% and 4 times faster on indexing and sorting (my work.) V 5.3 on an Amiga3000 is faster at many things than an IBM RS/6000 (a 18 MIPS $20K computer, folks). >Also of importance is that very little work was required to make >a program written for dBMAN work with FoxBase. The format of ...or work with Clipper, or dBase. This is our primary purpose. >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. Thank you. They were fun to write. > There is a capability for handling arrays, although the >designers chose to use []'s for subscripts instead of ()'s. >(Clipper uses []'s also.) This is standard. Why would we use ()'s? To be like BASIC? >The report writer is powerful, although plagued with the sort of >idiosyncrasies found elsewhere in dBMAN. Numeric fields will be That's what I'm working on this week :-) Really though, it works great for a great many people. >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. Well, I spent those weeks and look at the thanks I get :-) Really, check out V 5.3. >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. Our index file structure is superior. Changing index file type would mean a complete re-write and a step backwards. >Robert Broughton a1040@mindlink.uucp > a1040%mindlink@wimsey.bc.ca > a1040%mindlink@van-bc.uucp --------------------------------------- Ben Discoe, amigaman trying his best to bring professional software to the computer he loves. VersaSoft: 723-9044. If you have dBMan, you know our tech support number. Ask to talk to Ben.