Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!usc!hacgate!ashtate!dbase!awd
From: awd@dbase.UUCP (Alastair Dallas)
Newsgroups: comp.databases
Subject: Re: dBASE IV - is this for real?
Summary: It's not that bad :-)
Keywords: slow, annoying, egregiously bad
Message-ID: <135@dbase.UUCP>
Date: 30 Jun 89 18:10:27 GMT
References: <9383@xanth.cs.odu.edu>
Organization: Ashton Tate Devlopment Center Glendale, Calif.
Lines: 72

In article <9383@xanth.cs.odu.edu>, aiko@cs.odu.edu (John K Hayes) writes:
> 
> This is to anyone at Ashton-Tate who may be listening.  I cannot believe they
> went ahead and put out something so bad as dBASE IV.  I am embarrassed for
> initiating it's purchase at my workplace.  It takes about 20 seconds just
> to load up enough to start listening - and most of this time is spent painting
> some ridiculous moving logo graphic and an extremely long and annoying
> license agreement (and this is on a 12 MHz machine).

Undocumented trick of the month: invoke dBASE IV with a /t on the command
line to avoid the opening graphic (but not the legal message).

> Everything it does seems to take about twice as long as dBASE III.  It's all
> very pretty - the BROWSE screens are a whole lot more pleasing to the eye as
> long as you don't mind waiting a year to shift columns around or just to sift
> through the data.  Ashton-tate seems to have sacrificed efficiency and speed
> for pretty screens with nice colors.

Not so.  Run some benchmarks and you'll see that almost nothing in dBASE IV
is slower than dBASE III.  Some operations (like queries) got a lot more
powerful and therefore take longer, but raw I/O is considerably faster
than III+.  Remember, you couldn't "shift columns around" in BROWSE in III+.

> They've also added a "feature" which forces any programs you try to run with
> dBASE IV to be "compiled" into dBASE IV object files before
> they are run. Then when they run they are just as slow as
> when they were interpreted line-by-line.

Run some tests--try a DO WHILE loop, for instance.  Compiled object files
execute an order of magnitude faster than line-by-line.  Obviously, you're
still upset by the slowness of the opening graphic :-)

> This is because they do not get linked (although there is some sort of LINK
> command which really does not link - I guess all it does is allow you to 
> distribute slow programs that cannot be edited - big help there; what to they
> think I use Clipper for?  and Clipper is fast).  So, with this "upgrade" you
> now have to wait for a program to compile before it is run and then it runs
> just as slowly as if it were not compiled.  AND...if you make any changes to
> the programs - you have to delete the old object file before running it or it
> just runs the old object file.  

If the object file is loaded into memory, it will be executed from memory.
If it is on disk, the time stamp of the object file is compared to the 
source program and it is automatically recompiled, if necessary.  If you
use the dBASE IV editor, the object file will be flushed, forcing a 
recompilation. You seem to be running your program, editing the source, 
rerunning it and expecting dBASE IV to know that you've changed something.
In the interest of speed, dBASE IV doesn't check the source file every time
it runs a program that is already in memory.  To force the recompile you
seem to want, issue a CLOSE PROCEDURE command before invoking your editor.

> I hope Ashton-Tate gives out free upgrades to dBASE IV to those of us who
> were stupid enough to pay piles of money for a near worthless copy of v 1.0
> (one of our operators has deleted her copy and replaced it with her old
> dBASE III).

As I understand it, there is some sort of free upgrade policy (but I don't
know the details).  As for continuing to use dBASE III, I'm sure that
not everyone needs the power and speed of dBASE IV (C'mon, I'm one of 
the authors, what do you want me to say?)

>     ---{john hayes}  Old Dominion University; Norfolk, Virginia USA
>                      internet: aiko@cs.odu.edu
>                      Home: (804) 622-8348     Work: (804) 460-2241 ext 134  
> 

/alastair/

Disclaimer: Did you hear about David Ramsey, the Apple employee who
was fired for what he said electronically?  Am I crazy for talking
unofficially like this?  Yes, but at least this disclaimer says that
these are my opinions, and not official Ashton-Tate news.