a1040@mindlink.UUCP (Robert Broughton) (12/02/90)
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.uucprodent@netcom.UUCP (Richard Noah) (12/04/90)
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.
a1040@mindlink.UUCP (Robert Broughton) (12/04/90)
> rodent@netcom.UUCP writes: > > > >>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? I received version 5.0 in January or February of 1990. I telephoned Versasoft in June, and asked if an update was forthcoming. The answer was no. >>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: Every bug reported here was reported to Versasoft, via FAX. This was before you started to work there, however. They even told me at one point that they were planning to put an Amiga programmer on the payroll. I was particularly annoyed by your tech support dept.'s response to the "Y/N" vs. "T/F" bug discussed above. The person who handled it made no effort to understand the problem. I wasn't talking about how logical fields were displayed on the screen, but how they were recorded in dBASE-compatible files. >> 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? No, to be like FoxPlus, FoxPro, and dBASE IV. This is a minor point anyway, as it is little trouble to change brackets to parentheses. >>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. Ask for a raise. And send an upgrade notice to Syntec A/S, Hamang terasse 63, N-1300 Sandvika, Norway. >>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. My suggestion is to do the same thing with index files that you did with .dbf files; Give users the choice of using dBMAN format, or dBASE-compatible format. -- Robert Broughton a1040@mindlink.uucp a1040%mindlink@wimsey.bc.ca a1040%mindlink@van-bc.uucp
yorkw@stable.ecn.purdue.edu (Willis F York) (12/04/90)
Mind If i ask the "estimated" cost of this "POWERFULL" and Overkill for my needs Program? Sounds Usefull. But I'd still want an AREXX port!. -- yorkw@ecn.purdue.edu Willis F York ---------------------------------------------- Macintosh... Proof that a Person can use a Computer all day and still not know ANYTHING about computers.
rodent@netcom.UUCP (Richard Noah) (12/05/90)
yorkw@stable.ecn.purdue.edu (Willis F York) writes: >Mind If i ask the "estimated" cost of this "POWERFULL" and Overkill for my >needs Program? Well, retail is $295 but if you browse an AmigaWorld, you'll see it going for $174, $199, or $209, or $167.95, depending where you look. This is a good deal for a database manager that sells for $1295.00 to $39,995.00 on other machine for the Exact Same Program. Whether or not it's overkill for your needs, whatever data/applications you create with dbMan are instantly portable to the majority of the computers in the world. Many people buy something like SuperBase and realizes it doesn't do one or more things they need. We do it all. >Sounds Usefull. But I'd still want an AREXX port!. Have an application in mind? Show us how you could use an ARexx port and we'll put one in. >yorkw@ecn.purdue.edu Willis F York >Macintosh... Proof that a Person can use a Computer all day and still >not know ANYTHING about computers. The Macintosh version is the slowest, ugliest thing I've ever seen. We're rewriting it, but frankly, I'd rather spend my time on the A3000 :-) If enough Amiga people buy dBMan, I can do that :-) -------------------------------- Ben Discoe, caltech escapee, amigoid and visionary.
limonce@pilot.njin.net (Tom Limoncelli) (12/05/90)
In article <18025@netcom.UUCP> rodent@netcom.UUCP (Richard Noah) writes: > >- 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! Nit-picky comments: (1) You can run two copies of the program simultaneously; therefore it should handle locking internally (allocate some shared memory, create some semaphores, it's not that difficult) (2) I don't have AmigaDOS 2.0 yet, but it was mentioned on the net as having all the locking one would need for #1. Can anyone from C-A say if SANA will include this kind of locking? >> 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". If one is porting code from a system that *does* have locking, then the calls should be benign. > 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). (Some other post asks for an application that would use AREXX and dbMAN.) I can think of tons applications that would be enhanced if they could access huge databases. An AREXX bbs could use the database for all the data storage. With ImageLink and dbMAN (if dbMAN supported AREXX) you could create a database that poped up real images (good for personnel management, real estate, etc.). I'm sure others could come up with many, many useful applications. Just some thoughts. I don't use dbMAN, nor am I involved with the company. (though I am looking for something on the level of Ashton-Tate's RapidFile for the Amiga.) Tom -- tlimonce@drew.edu Tom Limoncelli "Flash! Flash! I love you! tlimonce@drew.bitnet +1 201 408 5389 ...but we only have fourteen tlimonce@drew.uucp limonce@pilot.njin.net hours to save the earth!"
ssd@sugar.hackercorp.com (Scott Denham) (12/08/90)
In article <18090@netcom.UUCP>, rodent@netcom.UUCP (Richard Noah) writes: > >Sounds Usefull. But I'd still want an AREXX port!. > > Have an application in mind? Show us how you could use an ARexx port and > we'll put one in. Well, here's an ARexx/Database application I've been needing for a while; I run a BBS-PC! system for a local Amiga users group, and while we like the reliability of BBS-PC!, its extensibility is, to be polite, very limited. I have figured out how to get reasonable communications in and out via an Arexx exec, and if I had an ARexx-equipped database program I could then provide online services like a membership directory, catalog of the club's PD library indexed by keyword, a decent index of the BBS file section, an indexed listing of other Amiga BBS's in the area, plugs for the vendors that donate demo copies to the club <grin>, etc. Scott Denham Club Amiga, Houston, Tx
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (12/09/90)
In article <18090@netcom.UUCP>, rodent@netcom.UUCP (Richard Noah) writes: > >> >Sounds Usefull. But I'd still want an AREXX port!. >> >> Have an application in mind? Show us how you could use an ARexx port and >> we'll put one in. You've GOT to be kidding, right? I mean a database is the single most natural platform for a full Arexx interface. Think about it... you fire up the 'engine', without the user interface, without requiring manual operator intervention (and you can use ARexx to fire it up in the first place). You then interact with it via ARexx alone, opening/closing databases, adding/deleting/updating records, searching for and retrieving records, sending parts or all of a record to a file or another application, or out the serial port or out the printer port or whatever else the user might think of. Jeez... no wonder databases are so dull. The authors of them have no imagination whatsoever. -larry -- The only things to survive a nuclear war will be cockroaches and IBM PCs. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
jep@mtiame.mtia.oz (Jesper Peterson) (12/10/90)
In article <2376@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes:
<You've GOT to be kidding, right? I mean a database is the single most natural
<platform for a full Arexx interface.
<
<Think about it... you fire up the 'engine', without the user interface, without
<requiring manual operator intervention (and you can use ARexx to fire it up in
<the first place). You then interact with it via ARexx alone, opening/closing
<databases, adding/deleting/updating records, searching for and retrieving
<records, sending parts or all of a record to a file or another application, or
<out the serial port or out the printer port or whatever else the user might
<think of.
SuperBase does this.
--
------------------------------------------------------------------------------
USEnet: jep@mtiame.mtia.oz.au UUCP: ...!uunet!munnari!mtiame.oz!jep
[...] I had to leave out reality to keep the post clean and to the point.
- jeremy@milton.u.washington.edu (Jeremy York) in rec.music.misc