Programmer 7500/MAX_PROGRAMMERS.iso/CLIPPER/DATABASE/DBFAST.ZIP/DBFAST

Text File | 1988-08-18 | 13.8 KB | 257 lines

DATE:    June 15th, 1988
TO:      ALL
FROM:    MELVIN L. NORELL
         Computer Information Center
         Glendale, CA
SUBJECT: A Review of the dBFast Compiler

Two  dBASE  III Plus compilers that have recently been announced
are the FORCE III Compiler by SOPHCO  in  Boulder,  CO  and  the
dBFast   Compiler   by   dBFast   Inc.  in  Issaquah,  WA.   The
advertisements, product releases and promotional  literature  on
both  of  these products are impressive enough that I considered
ordering a copy of each product for my review and consideration.

Last Thursday, I ordered a copy of  the  dBFast  Compiler  being
advertised  in  the  May  issue  of BYTE Magazine at the cost of
$69.00.  Upon talking to the salesperson I was informed that the
price of the compiler was now $99.00 and that it  was  "still  a
good  bargain  for  the price."  I asked if the 60 day Guarantee
was still included and the salesperson assured me that  it  was.
I asked that the compiler be sent UPS 2nd Day Air and my invoice
for  $109.00  reflects  that.   Today,  Tuesday,  I received the
dBFast Compiler, one day late.

The dBFast Compiler comes on a 5-1/4" floppy diskette,  together
with  a  200  page  soft-bound,  6"  x  9" reference guide.  The
reference guide is relatively easy to read and the material  has
been  organized  in a logical usable sequence.  The normal Table
of Contents and Index cross reference the  manual  in  a  manner
that you would expect any technical reference manual to do.  The
reference  guide  is  sub-divided  into  the  following  logical
groups:

        Getting Started
        Compiling & Running Programs
        Command & Functions
        Using dBFast on a LAN
        Compiler Error Messages
        Runtime Error Messages
        Index
        The dBFast Editor

dBFast is a compiler for  the  dBASE  III  Plus  language.   The
compiler  uses  the  concept of a memory or RAM-resident runtime
library,  much  like  the  same  idea  used  in  the   MicroSoft
QUICKBASIC  compiler  with the BRUN40 library.  According to the
manufacturer, "dBFast's unique technology results in  incredible
execution  speeds,  and compile times...".  Let me tell you that
there is NOTHING unique  about  their  technology!   The  dBFast
"engine,"  as commonly referred to by the manufacturer, is a TSR
program that takes up 86K of RAM memory.  You need to  have  the
dBFAST  engine  loaded  prior  to  doing any compilations and/or
running a compiled program.  The manufacturer supplies a utility
that allows  the  dBFast  engine  to  be  removed  from  memory.
Included  with the package is a full-screen programmer's editor,
complete with pull-down menus and user configurable options.  At
first glance, the editor appears to be  feature  rich  and  well
thoughtout; however, "I need to learn another editor like...I'll
stick  with BRIEF!"  Sixty pages of the reference guide document
the usage of the editor.  I did not spend any time reviewing the
editor program supplied with dBFast, however, I  did  read  that
portion  of the manual that deals with the compiler, the command
language and functions.

dBFast does not support the ANSI Terminal Protocol.   Therefore,
you  must  run  the  system on a standard IBM or 100% compatible
computer.  This causes a problem right away for our shop because
we do have several customers that  do  use  compatible  machines
that  are  not  100%  IBM  compatible.   Listed  below  are  the
specifications listed for the dBFast compiler.

        1 Billion       Max number of records
        2 Billion       Max number of bytes / dbf
        4000            Max number of memory variables
        65535           Memory available for memory variables
        4000            Max number of bytes / record
        128             Max number of fields / record
        254             Bytes / Character field
        8               Bytes / Date field
        1               Byte / Logical field
        N/A             Max Editor Capacity for Memo fields
        19              Bytes / Numeric field
        10              Max number of open databases
        7               Max number of open indexes / dbf
        64              Max number of open format files
        512             Max command line length
        65535           Max size of Program File (.PRG)
        196605          Max size of compiled file
        128             Max number of procedures / compiled prg
        20              Max number of program loop nesting lvls

dBFast Inc. allows you  to  give  away  any  programs  that  are
created  using the dBFast compiler.  They also allow you to give
away the dBFast engine and the program that removes  the  engine
from  memory  (a  good  idea since none of the compiled programs
will work without the engine.)

In evaluating any new product, I normally place a  big  emphasis
on  the working environment; that is, how much of an impact will
the  product  cause  and  demand  from  our   established   shop
procedures.   To  give  dBFast a fair and unbiased evaluation, I
decided to parallel  the  development  of  a  Church  Management
Information  System that our shop is currently doing for a local
non-profit organization.  I would  attempt  to  generate  normal
unmodifed  dBASE  III  Plus  code  for dBFast and the same thing
would be done for DBXL/QUICKSILVER.  We normally use GENIFER  to
generate  the  code  for  the  systems  that  we develop and the
GENIFER SOLUTION to clean up programs for DBXL/QUICKSILVER.   If
dBFast is as compatible and wonderful as the manufacturer claims
it  to  be,  then  this  compiler  should  be able to accept the
unmodified code generated directly out of GENIFER.

My story  begins  with  an  actual  Screen  Maintenance  Program
generated  by  the  GENIFER Applications Generator.  The program
was generated as a normal file containing the usual main program
followed by the procedure modules.  Two copies  of  the  program
were  made--one  for  dBFast and the other for DBXL/QUICKSILVER.
The first copy of the program was split into two separate files.
One file contains the main program and I called  it  MLMAIN.PRG;
the  other  file  contains the procedure modules and I called it
MLMAINP.PRG.  A "SET PROCEDURE TO MLMAINP" command was added  to
the main program so that it could recognize its procedure file.

dBFast,  like  QS,  has  the  capability  of  compiling external
Program and Procedure files.  The compiler handles this function
automatically, and it is the only  mechanism  available  to  the
programmer  to compile a large multi-program application.  There
are no provisions for the  independent  compilation  of  various
programs  and  no  link  step  is  ever used.  dBFast produces a
running .EXE file as the result of the compilation.

My first attempt at compiling the MLMAIN program  proved  to  be
unsuccessful.   I received 86 error messages; all about a SYNTAX
ERROR with "ENDIF" commands.  Listed below  each  error  message
was  the  cryptic  note: "An error occurred while trying to open
the .FRM form file LINE #: xxx."  Humm?  My program doesn't  use
any  .FRM  form files!  I would have to check the PROCEDURE File
to see which statement(s) were causing the problem.  At first, I
thought that the problem could be due to the fact  that  GENIFER
generates  a  comment  after each ENDIF command.  I proceeded to
remove the comment from each and every ENDIF  in  the  PROCEDURE
file.   Attempt  two  to  compile the MLMAIN program yielded the
same results.  This time I removed the comments from each ENDDO,
which GENIFER also provides.  Attempt three  to  compile  failed
also.   By  this  time,  I am wondering why would a program that
works in dBASE III +  without  errors  doesn't  compile  with  a
compiler that claims to be dBASE III + compatible.

Earlier,  in  reading  the  manual, I had remembered that dBFast
limits the number of program loop nesting levels to twenty (20).
Now, I know for sure that at the most, GENIFER only issues three
(3) nest levels for IF/ENDIF commands.  I would  hope  that  the
compiler  designer  and  coder(s)  did  not make the traditional
mistake of counting IF  statements  and  quit  after  the  20th.
(This  is  a  common  problem  found  in compiler design classes
taught at the university level)  To verify that this was not the
case, I went back  to  the  MLMAINP  PROCEDURE  File  and  began
counting  IF/ENDIF  blocks.   I  couldn't  believe  it when upon
counting the 20th IF/ENDIF block, the very  next  block's  ENDIF
was  the  first  line statement flagged by the compiler to be in
error.  The ENDIF statement of every IF/ENDIF block  after  that
was  also  flagged by the compiler to be in error.  SHAME DBFAST
INC.  --  YOU  NEVER  TESTED  YOUR  COMPILER  WITH  ANY  NORMAL,
REASONABLY SIZE DBASE PROGRAM.

With  this  FATAL error in the dBFast compiler, it is impossible
for me to continue my review of the product,  and  consequently,
prompted  me to pack dBFast and send it back from whence it came
from.  End of my review story.

Since I did  take  the  time  to  read  and  review  the  dBFast
reference  guide,  I'll  like  to give you my honest opinion and
comments on the dBFast Compiler product.  First,  I  think  that
dBFast  Inc.  has attempted to develop its compiler for a target
market that does not include the business program developer.  It
appears that dBFast is targeted  at  the  casual  dBASE  program
developer,  who strictly codes in dBASE and never uses any other
language to interface to his/her program.  Second, this  product
has  been developed in a hurry to attempt to capture the growing
dBASE compiler market, and consequently, FATAL errors  like  the
one  that  I  encountered  are never caught, because the company
wants to get the product "out the door."   Third,  many  of  the
commands  and  functions  implemented  by  dBFast are limited in
scope and prevent the applications developer  from  implementing
sophisticated  programs.   The  rest  of the text in this review
discusses the commands  and  functions  as  implemented  by  the
dBFast Compiler.

dBFast  imposes  some  restrictions which normally present minor
problems to the program developer.  All program files must  have
the  extension  .PRG.   If  .MEM  files are used in SAVE/RESTORE
operations, then the extension can only be .MEM.  All files used
with extension .PRG, .NDX, .FMT, .LBL and .FRM must  be  on  the
same  drive  and  sub-directory  as  the  .PRG file that you are
attempting to  compile.   You  must  have  at  least  one  space
following  a  command.   There  must  not  be  a space between a
function and its specification argument.

dBFast limits the user to 128 called procedures within a  single
set  of programs.  This means that it doesn't matter if you have
used the SET PROCEDURE command or not, each "DO program"  counts
as a separate procedure.  In theory, you are limited to 128 sub-
programs per compiled module.  dBFast overcomes this restriction
by  giving the user the CHAIN command, which allows one compiled
module to call another up to one nesting level deep.

The SET FILTER TO command cannot use the & macro substitution to
set the filter expression.  This is a SERIOUS  LIMITATION  which
creates massive amounts of programming work to code around.  All
of  the  programs generated by GENIFER have a generalized Filter
routine which allow the user to  set  any  filter  condition  or
conditions.   This limitation of the dBFast compiler would cause
us a substantial amount of reprogramming work.  In addition, the
SET FILTER TO command is only supported in the mode in which the
expression is stated at compile time... Auuuugggg!

Index files opened with the USE...INDEX or SET INDEX TO commands
must be present when the  program  is  compiled.   The  compiler
actually  opens  the index file and gets the index expression at
compile time rather than at runtime.  This means that  you  have
to  have  your .DBF and .NDX files within the sub-directory that
you are compiling from.  To overcome this unusual implementation
of these commands, dBFast has the SET NDXEXP FOR <index  number>
TO <index expression> command.

The  &  Macro  Substitution  function  cannot be used to replace
entire commands or  modifiers  in  command  lines.   The  dBFast
compiler  treats  variables  as  literal variables.  It does not
expand a macro...it treats the variable as a variable.  Embedded
Macros are not supported.  Macros that  are  actual  expressions
and  not  a  single  variable  are  not supported.  This SERIOUS
LIMITATION of the & Macro Substitution function  in  my  opinion
makes the dBFast Compiler TOTALLY USELESS.

On  the  LAN  side of things, dBFast does implement the standard
RLOCK(), LOCK(), FLOCK(), and UNLOCK() commands found  in  dBASE
III  Plus.  dBFast also implements a SET AUTOLOCK ON/OFF command
similar to QS and an RLOCKRE (Rlock with a Re-Read).

In conclusion, I like to offer the people at dBFast Inc.  a  bit
of  free  advise...Pull  this compiler off the market and get it
tested and upgraded to a level where companies like mine,  doing
real  business  applications,  can  begin  making use of it.  It
makes no sense to release a premature product as in the case  of
dBFast,  to  have  people like myself attempt to use it and then
find that its performance and features are poor.  Also, get  rid
of  the  handling fee that you charge on returns.  It only makes
me think that dBFast doesn't believe in what they  are  selling.
On  the  bright  side, I think that the dBFast compiler offers a
unique approach at solving the speed problem and the  .EXE  file
size  problem  encountered  with  both  QS  and  CLIPPER.  Maybe
WORDTECH should consider the concept of implementing a  run-time
library  module that is memory resident at execution time.  What
do you think?

-FIN-